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

[Jonathan Larmour]

Atte Kojo wrote:
> 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 believe the idea is that the sys layer functions should be safe to be 
called from the tcpip thread or from users of the raw API, which could have 
other timeouts associated with it that may expire sooner than any other 
particular call.

It just so happens that lwip_select is the only user of sys_arch_sem_wait, 
and the BSD sockets API only works over the sequential API, i.e. with the 
tcpip thread anyway. In that environment the only lwip timeouts other than 
for the tcpip thread (and maybe PPP thread) are just for select, and 
nothing else.

But I don't think changing this would be very future-proof. And it's 
possible that raw API users already use sys_sem_wait_timeout. Maybe it 
could be an option though?

> 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). :-)

I think that would be a bad idea. Packet-oriented netbufs can be used more 
efficiently than streams, and you can't do things like netbuf_ref() etc. 
with streams.

Jifl
--
eCosCentric Ltd  http://www.eCosCentric.com/  The eCos and RedBoot experts
  **  Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv> **
  **  April 3-5 2007, Booth 1922, San Jose McEnery Convention Center  **
Company legal info, address and number:   http://www.ecoscentric.com/legal
------["The best things in life aren't things."]------      Opinions==mine