[lwip-users] RE: [lwip] Q: implementation for select()

[Recker, John]

I am *way* behind on this mailing list, but I have implemented
a limited version of select - in particular, it only waits on
new incoming data and connections. send() blocks,
so select() on write is redundant in my implementation. Note
that I also added a ioctl() that allowed recv() to be non-blocking,
otherwise select() is somewhat redundant. I successfully ported
the HP PicoChai server which is built around select to this socket
library.

In addition to the select() function (which is 
relatively easy), I added a the following new
internal functions (this is on 0.5.3).

I'd be happy to share my code with someone that
could integrate it back into the main source tree.

jr

=============================================================

to api_lib.c:
=============

netconn_recv_avail(struct netconn *conn, struct netbuf **nb, u16_t timeout)

 this function tests whether there is data available
 on conn->recvmbox. If not, it blocks until data is available
 or for timeout msecs before returning

netconn_accept_avail(struct netconn *conn, u16_t timeout)

 same as above but on conn->acceptmbox

netconn_accept_recv_list_avail(struct netconn **conn, 
                               int *count, 
                               u16_t timeout)

 same as above but on a list of connections

to sys_arch.c
=============

sys_mbox_peek(struct sys_mbox *mbox, void **msg, u16_t timeout)

 This function is exactly analogous to sys_arch_mbox_fetch(),
 except that mbox->first is not updated (eg the data on
 the list handing off the mbox is not popped off the list)

sys_mbox_list_peek(sys_mbox_t *mbox,
                                   int *count,
                                   void **msg, 
                                   u16_t timeout)

  analogous to sys_mbox_peek() except that it blocks on a list
  of mbox's rather than one.

sys_arch_sem_list_wait(struct sys_sem **sem, int *count, u16_t to)

  analogous to sys_arch_sem_wait except returns when any one of 
  a list of semaphores are pinged. This function is the core
  of select(). I ended up implementing OS specific versions of this
  function, but creating a new thread for each sem in the list and 
  calling sys_arch_sem_wait() from each thread is essentially what I
  implemented on Ecos (This is analogous to the windows
  WaitForMultipleObjects() function). The part that demanded care
  was properly cleaning up all these new threads prior to return.



-----Original Message-----
From: address@hidden [mailto:address@hidden
Sent: Wednesday, August 07, 2002 5:25 AM
To: address@hidden
Subject: Re: [lwip] Q: implementation for select()


Hi!

> All the 'socket' stuff is ultimately based on the 'low-level interface'.
> The 'low-level interface' is a callback interface that gives you all the
> information that 'select' does (and then some). Also, crucially, for an
> embedded platform, it only executes 'user code' when there is something
> for that to do.
> Why not use that, rather than the 'socket' code?
> You won't need threads/semaphores either!

Yes it can be done of course with the raw API but the TCP IP Stack for AROS
which is based on lwip needs to provide a bsd socket layer and also
select(). The more complete it is the better.

Ciao,
Sebastian


[This message was sent through the lwip discussion list.]
[This message was sent through the lwip discussion list.]