[En-Nut-Discussion] select() implementation / Re-Integration of the "devnut_select" branch
ole.reinhardt at embedded-it.de
Thu Oct 24 12:54:25 CEST 2013
> I mainly just thought that a nice way to implement it would be to have an
> implementation of the select function which uses the same time units that
> NutOS thinks in and layer other implementations on top of it, which would allow
> for the use of macros to do the time conversion when constant values were used.
Ah ok. I understand your thoughts.
But all other timeouts and the NutSleep as well just use ms as timeout
Btw: With the latest Nut/OS, the native time calculation is based on a
timeval struct, and depending on the system tick resolution it could be
accurate up to a µs (while most implementations use a 1Khz system tick
As soon as I implemented poll() as alternative to select() as well, you
will be able to use the native resoltion for timeouts (ms) without the
need for further conversions as well.
> I'm excited about the select function being added to NutOS. I couldn't
> figure out
> an easy way to implement that functionality, but it would have helped me
> out a lot
> in the past.
Just have a look into my code :)
Indeed it was quite tricky and needed several low-level modifications in
the way filedescriptors where implemented.
The most complicate part was to find a way how multiple threads could
wait for several events.
Just have a look into nut/crt/select.c (do_select() and select_scan())
To make that work, a new device callback (dev_select()) was added to the
NutDevice struct. It's a callback into the driver that will tell you, if
data is available or not.
Further more, each driver that supports select() needs to implement a
wait_queue (new type) which will be signalled as soon as data gets
The rest is more or less the standard implementation. :-)
kernel concepts GmbH Tel: +49-271-771091-14
Sieghuetter Hauptweg 48 Mob: +49-177-7420433
More information about the En-Nut-Discussion