lwip-users
[Top][All Lists]
Advanced

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

RE: [lwip-users] Problem with lwip_close()


From: Goldschmidt Simon
Subject: RE: [lwip-users] Problem with lwip_close()
Date: Fri, 6 Jul 2007 14:47:10 +0200

Hi,
 
those are two different things you are seeing:
The lwip_close function does two things:
- close the connection
- free all pbufs that are received but not yet processed.
 
The first is what SO_LINGER would change (waiting to output all data vs. telling the stack to close and letting it output in the background).
The latter is necessary to prevent memory leaks and can't be changed! If you get stuck there it obviously is a bug in lwIP or your port.
(I'd suggest it is in your port since noone else reported such a problem, but convince me of the opposite! ;-)
 
You could take a look at the contents of conn->recvmbox before calling sys_arch_mbox_fetch.
 
A problem in your port could possibly be your implementation of sys_arch_timeouts() (in sys_arch.c). It should return a pointer
that is unique to each thread. Did you port yourself or use an existing (working) port?
 
 
Simon
 


From: address@hidden [mailto:address@hidden On Behalf Of address@hidden
Sent: Friday, July 06, 2007 2:37 PM
To: Mailing list for lwIP users
Subject: RE: [lwip-users] Problem with lwip_close()


Hello again,

the Version I am using is V. 1.1.1

And the lwip_close function gets stuck exactly in the next piece of code inside netconn_delete():

err_t
netconn_delete(struct netconn *conn)
{
 ...

  /* Drain the recvmbox. */
  if (conn->recvmbox != SYS_MBOX_NULL) {        
    while (sys_arch_mbox_fetch(conn->recvmbox, &mem, 1) != SYS_ARCH_TIMEOUT) {
      if (conn->type == NETCONN_TCP) {                
        if(mem != NULL)                                
          pbuf_free((struct pbuf *)mem);
      } else {
        netbuf_delete((struct netbuf *)mem);
      }
    }                                                 ->It does not get off the while. It gets stuck, and if I stop the debugger I see that the execution has gone along some other files reaching the
    sys_mbox_free(conn->recvmbox);                //main loop in tcpip.c.
    conn->recvmbox = SYS_MBOX_NULL;
  }

...

}

After seeing this, I think that what the lwip_close() function does is close the socket gracefully getting blocked until the whole handshake has been properly completed. Am I right?? 
 
If this is ok, is there any possibility of implementing a linger close?

Thank you very much for your attention.

Borja.




"Goldschmidt Simon" <address@hidden>
Enviado por: address@hidden

06/07/2007 12:32

Por favor, responda a
Mailing list for lwIP users <address@hidden>

Para
"Mailing list for lwIP users" <address@hidden>
cc
Asunto
RE: [lwip-users] Problem with lwip_close()





 
> I have been studying how to make a linger close of a socket in lwip.
> First of all, I have used the standard lwip_close() function as it is,
> an I have noticed that it gets stucked in  the
"netconn_delete(sock->conn);"
> statement. I suppose that here it will wait for the closure handshake
to
> get completed or something like that.
>

That's strange. Can you tell us which version of lwIP you're using and
do
you know why it got stuck? (e.g. memory problems?)

> Later, I tried to see how to use the SO_LINGER option. And I saw that
this
> option is listed in sockets.h but I cannot find it in sockets.c. I had
a
> look in lwip_setsockopt(), but I did not find the SO_LINGER
definition.
> In addition, I saw that many other options are unimplemented. Then, my
> question is: Can a linger close be implemented under lwip?? How??
Usingo the
> SO_LINGER option in setsockopt ???

I don't know if I remember correctly, but I think the last SO_LINGER
implementation
wasn't working correctly and because of that, the code was removed.
I is one point of the lwIP todo-list to implement SO_LINGER, though.


Simon


_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users


reply via email to

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