Note: I don't really understand your idea. Could you please explain it
again?
> 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.
If I understand this bit, it won't work because you call select(2) or
poll(2) with a truckload of FDs, not just one.
> 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.
Since you seem to be talking about a completely different mechanism
(at the API level), how about explaining it without reference to
select(2) or poll(2)? It might be less confusing.
> 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
Still don't get what you're saying.
> 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.
Note that from the point of view of the application, select(2) and
poll(2) are effectively event driven: the process gets woken up when
an event (FD becomes active) occurs. The application doesn't know what
is happening under the hood.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu