>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...
====================================
Frédéric BERNON
HYMATOM SA
Chef de projet informatique
Microsoft Certified Professional
Tél. : +33 (0)4-67-87-61-10
Fax. : +33 (0)4-67-70-85-44
Email : address@hidden
Web Site : http://www.hymatom.fr
====================================
P Avant d'imprimer, penser à l'environnement
-----Message d'origine-----
De : address@hidden [mailto:address@hidden De la part de geckook Xu
Envoyé : mercredi 21 mars 2007 04:16
À : lwip-devel
Objet : Re: [lwip-devel] [bug #19345] tcpip_apimsg+api_msg_post problem
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.
Do you meet the condition that MEMP_TCP_SEG can not be free in some case.
On 3/21/07, Frédéric Bernon <address@hidden> wrote:
>
> Follow-up Comment #5, bug #19345 (project lwip):
>
> I join a patch to solve the problem, and to improve reliability (and
> code is more simple).
>
> "api_lib.c, tcpip.c: integrate sys_mbox_fetch(conn->mbox, NULL) calls
> from api_lib.c to tcpip.c's tcpip_apimsg(). Now, use a local variable
> and not a dynamic one from memp to send tcpip_msg to tcpip_thread in a
> synchrone call. Free tcpip_msg from tcpip_apimsg is not done in
> tcpip_thread. This give a faster and more reliable communication
> between api_lib and tcpip."
>
> Patch file is attached.
>
> If no objection, I will commit it tomorrow...
>
>
> (file #12223)
> _______________________________________________________
>
> Additional Item Attachment:
>
> File name: tcpip_apimsg.patch Size:5 KB
>
>
> _______________________________________________________
>
> Reply to this item at:
>
> <http://savannah.nongnu.org/bugs/?19345>
>
> _______________________________________________
> Message posté via/par Savannah
> http://savannah.nongnu.org/
>
>
>
> _______________________________________________
> lwip-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-devel
>
_______________________________________________
lwip-devel mailing list
address@hidden http://lists.nongnu.org/mailman/listinfo/lwip-devel
_______________________________________________
lwip-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-devel