Andrew, does the IO framework support non-IO wakeup of threads yet? I
think that's the key to eliminating the serializer and
getting message delivery into the thread pool. I'd like to be able to
mark a queue so that it can wake an IO thread when it's got messages.
I think we can drive message delivery from IO wakeups like this:
Producer ready-to-read wakeup: only goes as far as enqueueing the message.
Consumer thread ready-to-write wakeup: visits queues that it consumes
from and
- if it finds messages, write until writing would block, then go back
to sleep.
- if there's not enough data to block writing, mark myself as an
"unsatisfied consumer" on all queues of interest.
- Any queue with unsatisfied consumers enables IO wakeups.
Queue-has-messages wakeup:
- write messages to unsatisfied consumers, writing until write would block.
- remove unsatisfied consumer marker for all consumers that are blocked
in write, leave it for any that are not.
The idea is that every consumer is always in exactly one of these states:
- blocked on write to network.
- blocked waiting for message from a set of queues.
- being serviced by a thread (which could be triggered by
ready-to-write or a queue-has-messages, but not both)
Does that make sense?
Cheers,
Alan.
