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
_______________________________________________
lwip-users mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/lwip-users