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

[Frédéric Bernon]

Follow-up Comment #7, bug #19345 (project lwip):

>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...

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?19345>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.nongnu.org/