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

[Paul Sheer]

On 2002.08.07 00: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 

NO!!!!!!!!!!

http://threading.2038bug.com/

explains all about select(). (although there is a lot about threads too.)

-paul

> 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...
> 
> 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.]
> 
Paul Sheer Consulting IT Services . . Tel . . . +27 (0)21 6869634
Email . . . address@hidden . . . . . . Pager . . . 088 0057245
Linux development, cryptography, recruitment,  support,  training
http://www.icon.co.za/~psheer . . . . http://rute.sourceforge.net
L I N U X . . . . . . . . . . . .  The Choice of a GNU Generation
[This message was sent through the lwip discussion list.]