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

[Duncan Palmer]

On Tuesday 06 August 2002 23:27, Rod Boyce wrote:
> Guys,
> In embedded programming sitting and waiting for something to happen is nota
> good idea.  All select does is wait for either a read or a write to happen
> on a file descriptor(s).  Why not just sit in a loop checking for the
> interesting events for each fd.  This is all your select is going to do,
> there is no magic involved.  This way you do not have to over burden our
> embedded systems with fd sets and the likes...

I guess it all depends on how small your embedded system is... mine has a 
preemptive os and runs between 20 and 30 tasks, and i often need to wait for 
stuff to happen. If I was working on something smaller, I'd agree with your 
sentiments ;) 

I spose that one alternative to having a fully functional select would be to 
provide an API to check fd's for their read and writeability - this would be 
fine for my application as i have no need for sets of fd's. But, I do need to 
use the sockets API and have to keep things reasonably portable, so i'd like 
to have the checks for read and writeability in lwip. If these are included 
in the sockets API, which most people on smaller embedded systems probably 
don't use, no-one will be overly burdened.

>
> Eg
> while no events loop
>       check fd1for interesting events
>       ...
>       check fdx for interesting events
>       (do some other processing if necessrary.)
> end loop.
>
> this way you can keep the rest of the task going.  Off course this all
> becomes unnecessrary if you are using a pre-emptive kernel of some
> discription.
>
> Rod
>
> PS I'm an embedded software guy on small micros 8 to 32-bits so I could
> very likely have the wrong end of the stick...:-)
>
> On Tue, 06 Aug 2002 10:17, Duncan Palmer wrote:
> > On Tuesday 06 August 2002 16:46, Sebastian Bauer wrote:
> > > Hi!
> > >
> > > > > Hello,
> > > > > Is there an implementation for select() in the socket library
> > > > > available? Where can I find it?
> > > > > That would be very useful for my application.
> > > >
> > > > I'd also like to have it. Which parts of the select functionality do
> > > > you
> > >
> > > need?
> > >
> > > I need at least the readfds.
> >
> > If you just have one fd in your list of readfd's, its pretty trivial -
> > you can just do a non-blocking read on conn->recvmbox. For more than one,
> > its a bit more work. Did you have any implementation ideas? I've just had
> > a bit of a think about it, and come up with this. What do you think?
> >
> > Add 2 lists of semaphores to each struct netconn - one to be used by
> > readfds and one by writefds. Add fields to the struct netconn's to enable
> > FD_SET and friends to be implemented.
> >
> > To implement readfd's: The select call will create a new semaphore and
> > add it to the list of semaphores on all connections which correspond to
> > its list of readfds. It will then wait on this semaphore. When new data
> > comes in (i.e. in all the places where conn->recvmbox is posted to),
> > signal all read semaphores on the connection. This will wake up the
> > select call which can delete the semaphore from all connections it was
> > waiting from and return.
> >
> > To implement writefds: If the connection is a UDP connection, it doesn't
> > block, so that's easy. If its a TCP connection, the select call creates a
> > new semaphore and adds it to the list of semaphores on all connections
> > which correspond to its list of writefds. Writes on TCP sockets block if
> > tcp_sndbuf(conn->pcb.tcp) == 0, and all writes result in a call to
> > sent_tcp() or err_tcp(). So, in each of these functions, signal all write
> > semaphores on the connection. This will wake up the select call which can
> > delete the semaphore from all connections it was waiting from and return.
> >
> > If we're awoken as a result of an error (conn->err is set), select needs
> > to return failure.
> >
> > This actually sounds easier than i thought it would be - does it look
> > correct to you?
> >
> > > Would be nice if somebody could implement this. Otherwise I will try it
> > > because it's quiet important for me.
> > > But then where do all the patches go which are sent to the list?
> > > Is there a cvs which I can access?
> > >
> > > Ciao,
> > > Sebastian
> > >
> > >
> > > [This message was sent through the lwip discussion list.]
> >
> > [This message was sent through the lwip discussion list.]
>
> [This message was sent through the lwip discussion list.]
[This message was sent through the lwip discussion list.]