lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE : [lwip-devel] [bug #19345] tcpip_apimsg+api_msg_post problem


From: Frédéric BERNON
Subject: RE : [lwip-devel] [bug #19345] tcpip_apimsg+api_msg_post problem
Date: Wed, 21 Mar 2007 12:44:45 +0100

>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

Attachment: Frédéric BERNON.vcf
Description: Frédéric BERNON.vcf


reply via email to

[Prev in Thread] Current Thread [Next in Thread]