On Thu, Dec 12, 2002 at 12:39:17AM -0800, Manoj Kasichainula wrote:
...
> > Add a descriptor (pipe, socket, whatever) to the pollset and use
> > it to indicate the need to generate a new pollset. The thread that sends
> > info down this descriptor could be programmed to wait a short amount of
> > time between sending triggers, so as not to cause the select() to return
> > too, too often, but short enough not to delay the handling of new
> > connections too long.
>
> But what's a good value?
...
> Hmmm, if the poll is waiting on fds for any length of time, it should be
> ok to interrupt it, because by definition it's not doing anything else.
>
> So maybe the way to go is to forget about waiting the 0.1 s to interrupt
> poll. Just notify it immediately when there's a fd waiting to be polled.
> If no other fds have work to provide, we add the new fds to the poll set
> and continue.
> Otherwise, just run through all the other fds that need handling first,
> then pick off all the fds that are waiting for polling and add them to
> the fd set.
>
> So (again using terms from my proposal):
>
> submit_ticket would push fds into a queue and write to new_event_pipe if
> the queue was empty when pushing.
>
> get_next_event would do something like:
>
> if (previous_poll_fds_remaining) {
> pick one off, call event handler for it
> }
> else {
> clean out new_event_queue and put values into new poll set
> poll(pollfds, io_timeout);
> call event handler for one of the returned pollfds
> }
...
+1 on concept with comments:
Each time poll returns to handle ready fds, it should skip new_event_pipe
(it should not send than fd to an event handler), and it should check
new_event_queue for fds to add to the pollset before it returns to polling.
It should always be doing useful work or should be blocking in select(),
because it will always have at least one fd -- it's end of new_event_pipe --
in its pollset.
Coding to interrupt the poll immediately is the first thing to do, and
then a max short delay can be added to submit_ticket only if necessary.
As you said, the max short delay would only affect the unbusy case where
the poll is waiting on all current members of the pollset. The short
delay had been suggested to prevent interrupting select() before select()
had a chance to do any useful work. We won't know if this is a real or
imagined problem until it is tested. It sounds like it won't be a
performance problem, although using the max short timer of even 0.05s might
slightly reduce the CPU usage of these threads when under heavy load.
-Glenn
