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

[Duncan Palmer]

On Wednesday 07 August 2002 12:06, Dirk Koopman wrote:
> Erm...
>
> Am I being a bit thick here or have I missed something?

Nope - what you're suggesting looks feasible to me, but i still want select() 
- read on...

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

I have a code base which needs to be portable, and assumes a unix like 
interface to the TCP/IP stack (which is lwip on one of my platforms). This is 
what the sockets layer is, and it is in the sockets layer that i think the 
code which uses the low-level interface to implement select() belongs. The 
platforms we are targetting are reasonably powerful, so the small overhead 
involved in using the sockets interface is irrelevant. 

Judging by everyone's comments, its pretty apparent that whatever way select 
is implemented, it'll have to be done so as not to have an negative 
(performance/memory usage) 

>
> Dirk
>
> On Tue, 2002-08-06 at 23:52, Sebastian Bauer wrote:
> > Hi!
> >
> > From: "Duncan Palmer" <address@hidden>
> >
> > >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.
> >
> > I'm not really familiar with the internals of lwip but this sounds well
> > for me. The only problem I see is that how select() knows now (after it
> > has been waken up) which netconn's received something? Or is it possible
> > to check this? (checking if there is anything in conn->recvmbox without
> > fetching).
> >
> > Also is there really the need that the netconn's should have lists? Maybe
> > just a refrence would be enough. I think only one task/process/thread can
> > receive something from a netconn.
> > That would make the implementation simpler.
> >
> > But I will think a little bit more about tomorrow :)
> >
> > 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.]