Re: [lwip-users] upgrade to 0.6.2

[Peter Graf]

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