RFC: implementing 'poll'.

[Hellbender]

Hi.

Still working on my VFS design. I try to come up with a fast yet still somewhat simple (from device point of view) way of implementing poll (i.e. waiting until one or more open files can be read/written).

I know how Linux implements it, so that is one option (i.e. devices add thread wait queues to a list maintained by kernel, device wait queue wakes the thread up once data can be transmitted, and kernel tears the list down). I don't like the overhead of building the list of wait queues, and tearing them down after every poll.

My latest iteration is based on an idea that a thread can execute only a single poll at a time, and that a thread typically keeps polling the same file handles over and over again. My device drivers are implemented as (possibly separate) service process(es), and the poll mechanism would be part of the VFS service. This is how it's supposed to work:

Each thread that does a poll has a 'poll request structure' (PRS) in the VFS service. It contains a 'poll request sequence counter' (PRSC) and the thread id.
When a thread does a poll, the PRSC value is incremented. All device drivers involved in the poll store the PRS handle (in practice VFS service pointer to the structure) and the current PRSC value to each file that is part of the poll. The thread would then sleep until it receives a signal. Once a polled file can be read/written, the driver would iterate all PRSs in the file and ask the VFS to wake up the thread. If the current PRSC value matches the PRSC value stored by the device, VFS increments the PRSC value and sends a 'SIGPOLL' signal to the thread. This would be implemented in such a way that only one file will trigger the signal. There would not be any poll structure tear-down until the file is closed, but PRSC value comparison would prevent sending excess signals if other files become readable/writable after the thread has been woken up. Later, when the thread does a new poll, device drivers would just update the PRSC values stored in the polled files, so that new data would trigger a new signal to wake up the thread.

Please comment if you find problems or flaws in my logic, and tell how you implement 'poll' in your OS.

[Combuster]

and tell how you implement 'poll' in your OS.

By refusing to have blocking calls and instead have devices send messages straight to the process when a resource becomes available.

For a more traditional synchronous poll, you could have polling objects maintained in the kernel, which is for most part about moving overhead around, possibly hiding it in another thread to make the calling thread look faster. I'd probably have an interface as follows
- CreatePollGroup
- DeletePollGroup
- AddObjectToPollGroup
- RemoveObjectFromPollGroup
- Poll
- PollWithTimeout

On average this causes more overhead in raw system call code instead of having a Poll(object, object, ...) function as you might need to update the stateful polling objects in between.