Wed 21 Mar 2007 05:09:06 PM UTC, comment #7:
>If you use the local variable to send tcpip_msg, it would still leave
>you with potential problems. because you didn't create an copy for this
>variable, the local variable will be unavliable when the program run to
>other area.
It "could be" true, but don't forget the tcpip_apimsg's call is block (inside the "struct tcpip_msg msg;" scope) by "sys_mbox_fetch(apimsg->msg.conn->mbox, NULL)" until tcpip_thread post it a "acknowledge" (and in all api_msg "do_xxx"; the "sys_mbox_post(msg->conn->mbox, NULL);" is "always" at the end). So, the variable can't be used outside the scope of tcpip_apisg. The "generic" process is that (simplified) :
App Thread
tcpip_apimsg()
{ struct tcpip_msg msg
post to tcpip_thread
sys_mbox_fetch(start wait...
tcpip_thread()
{ sys_mbox_fetch()
api_msg_input()
do_xxxx()
{ // message process
sys_mbox_post(msg->conn->mbox, NULL);
}
}
End wait...)
}
I say "always", but there is some exceptions. This is my check list :
do_newconn => sys_mbox_post(msg->conn->mbox, NULL) at the end, but if (msg->conn->pcb.tcp != NULL), it is called immediatly
do_delconn => sys_mbox_post(msg->conn->mbox, NULL) at the end, but with a (msg->conn->mbox != SYS_MBOX_NULL) check
do_bind => sys_mbox_post(msg->conn->mbox, NULL) at the end
do_connect => multiples sys_mbox_post(msg->conn->mbox, NULL) with return just after
do_disconnect => sys_mbox_post(msg->conn->mbox, NULL) at the end
do_listen => sys_mbox_post(msg->conn->mbox, NULL) at the end
do_accept => !!!! no "direct" process? And YES, this can be a problem... But in fact, do_accept do nothing, can its call could be avoid, because never use (will have to be suppress)...
do_send => sys_mbox_post(msg->conn->mbox, NULL) at the end
do_recv => sys_mbox_post(msg->conn->mbox, NULL) at the end
do_write => sys_mbox_post(msg->conn->mbox, NULL) at the end
do_close => sys_mbox_post(msg->conn->mbox, NULL) at the end
do_join_leave_group => sys_mbox_post(msg->conn->mbox, NULL) at the end
Some extras calls:
do_connected: => when a tcp connection is really connected, sys_mbox_post(msg->conn->mbox, NULL) est call.
err_tcp => called when tcp error, and all conn's mailboxes receive a NULL message (recvmbox, mbox, acceptmbox).
Last, I you really want to be sure, you can write something like :
void
api_msg_input(struct api_msg *msg)
{ struct api_msg_msg msg_copy;
msg_copy=msg->msg;
decode[msg->type](&msg_copy);
}
This will stay faster than using memp...
About this part, agree to commit?
>Do you meet the condition that MEMP_TCP_SEG can not be free in some
>case.
I don't understand this question (in this context) ? But no, I don't meet this condition. Of course, I will tell you if I see something like that...
|