Re: [lwip-users] Why does sys_sem_wait_timeout exist?

[Atte Kojo]

Kieran Mansley wrote:
> On Tue, 2007-02-27 at 11:43 +0200, Atte Kojo wrote:
>   
> > As far as I understand sys_arch_sem_wait is guaranteed to exist, so why 
> > implement redundant functionality for just one function (lwip_select).
> >     
> Erk, can't remember - too long ago!  If this is causing a problem I
> might be able to look into it, but my best guess is that it's a code
> cleanness thing. i.e. perhaps it wasn't intended to be using the
> sys_arch_* code up in the sockets layer.
>   
I don't think it's causing any problems, it just seems rather 
cumbersome. What comes to using sys_arch_* code in upper layers, all 
semaphore functions except sys_sem_wait are implemented in sys_arch.c 
anyway (same thing for *mbox* functions); the naming scheme is not the 
most logical here.

As there has been quite a lot of confusion about using timers in the 
past, I'd like to propose the following: replace all the 
sys_mbox_fetch() and sys_sem_wait() functions in the 
socket/netconn-layer with their sys_arch-counterparts and implement the 
timer functionality only in tcpip_thread. Or better yet, rename 
sys_arch_sem_wait() -> sys_sem_wait() and sys_arch_mbox_fetch() -> 
sys_arch_mbox_fetch() and implement a special timer mechanism for 
tcpip_thread.

Unfortunately I cannot really help with the coding since the code I use 
differs in parts quite a lot from the original code (expert advice: 
never EVER try to implement a TCP/IP stack for a DSP that doesn't do 
byte addressing).

PS. Since I'm wishing stuff here, I'd also like to see netconn API 
merged into the socket API (netbuf stuff could probably be thrown away 
in the same haul). :-)

- Atte