Re: [lwip-users] upgrade to 0.6.2

[Ed Sutter]

More on this...
Is there any chance that netconn_delete() was not updated to
match the change made to the return logic of sys_arch_mbox_fetch()?

At some point between January 2003 and now, the return strategy
for sys_arch_mbox_fetch() was changed so that a timeout would return
0xffffffff instead of 0 (right?).
Assuming that's true, then shouldn't the code in netconn_delete() have
been updated to reflect this?  
I looked at my version of netconn_delete() from January (which
was prior to the change made to sys_arch_mbox_fetch(), and the one
that I just picked up with 0.6.2, and it doesn't look like the
appropriate change has been made.

I've become more suspicious of this because I made the change in
my copy and now lwip_close() (and everything else) is working fine
for me.

Am I confused (yea, probably) or does netconn_delete() need to be
updated?

Ed

Peter Graf wrote:
> 
> Hi,
> 
> >My priorities look ok (tcpip_thread is higher than all others).
> >I'm finding that lwip_close() is hanging up in netconn_delete()
> >because netconn_delete() is draining the receive mailbox by
> >looping on a non-zero return from sys_arch_mbox_fetch().
> >
> >At this point in my system, sys_arch_mbox_fetch() is always
> >returning 0xffffffff because there is no mail so it times out.
> >I haven't looked at this code much, but it seems like there
> >should be a differentiation between 0xffffffff and all other
> >non-zero values returned here.  However, since this works for
> >everyone else, I must have a bug in my sys_arch_mbox_fetch()
> >return code logic.
> 
> No, it does not work for everyone else :-(
> 
> I have also found that netconn_delete(), called by lwip_close(), doesn't
> return, unless the other endpoint had closed connection before. It seems
> that this problem could be timing dependent. Unfortunately I have no
> debugger for my target, so I had had to give up for now.
> 
> I'm pretty sure that my semaphore code in sys_arch.c is clean, since the
> change from 0.5.3 was trivial.
> 
> I have two other remarks:
> 
> 1. Style: It was long time lwIP tradition to stick with "/* ... */" comments,
> but now "// ..." starts to get used. My C compiler can't deal with it. Can we
> go back to "/* ... */" only?
> 
> lwip/src/core/pbuf.c, line 298:
> //q->next = NULL;
> 
> lwip/src/core/udp.c, line 60
> //#undef DEBUGF
> //#define DEBUGF(x,y) { page_printf("\f"); page_printf y; };
> 
> 2. sockets.c: All calls to sys_sem_wait() in sockets.c are introduced by
> 
> if (!...)
>    ... = sys_sem_new(1);
> 
> except for lwip_accept(), where sys_sem_wait() could be used on
> non-allocated semaphore. Shouldn't allocation be added here, too?
> 
> (BTW This construction is not thread-save. A task switch could occur
> between the decision that the semaphore needs creation and the actual
> call of sys_sem_new.)
> 
> Generally wouldn't it be better to allocate the semaphore only once,
> at lwip startup?
> 
> All the best
> Peter
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/lwip-users