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

[Rod Boyce]

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

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.]