Messages in this thread | | | From | Perry Harrington <> | Subject | Idea for select/poll speedup | Date | Sat, 20 Jun 1998 23:42:05 -0700 (PDT) |
| |
I know that select and poll are implemented totally different than my proposal, but it's worth mentioning I think.
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
| |