Ok, the problem with select and poll is that they scan a list of
FDs and do not provide a wake one capability. The wake one issue is
not specifically addressed by my idea.
Anyhow, the idea is this:
For each call to select/poll, you would do this:
Attach a "poll" structure to the fd being scanned. When an event
(read, interrupt and subsequent data handling) happens on that
fd, scan the poll linked list, move the structures back into the
processes head node, and set that process to wakeup in it's next
timeslice.
I don't know if this can be done within the semantics of select or
poll. The idea is that select and poll simply set a bunch of
callback (not REAL callbacks) event notifications on the FDs being
polled.
This solution has 3 benefits:
- select/poll do not scan the list
- FDs ready for action are placed in another list, rather than
doing "for 1 to n ... FD_ISSET(y)"
- file descriptor changes are handled in an event driven manner rather
than polled
So, I'm just throwing this idea out there because I haven't seen anyone
address this issue about select/poll problems.
Using select/poll is very useful in network applications. I believe
that an event driven implementation is much more scalable than a polled
solution; we need scalable implmentations in Linux, to keep up with
the rest of the capabilies of the OS.
--Perry
-- Perry Harrington Linux rules all OSes. APSoft () email: perry@apsoft.com Think Blue. /\- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu