Queue that provides a notification mechanism for when new items were added
Generic interfaces and logic for RequestQueues and related classes.
Genericly speaking, a request handler delegate is being registered at
the queue (ready()). The notifying queue will then call notify() to inform
it about a new item added, notify() is expected to call pop() to receive
that item. It should keep calling pop() until no items are left
and then re-register at the queue and wait for another call to notify().
In other words:
1. NotifyingQueue.ready(¬ify)
2. NotifyingQueue.ready calls notify()
3. notify() calls NotifyingQueue.pop();
* pop() returned a request: notify() processes data, back to 3.
* pop() returned null: continue to 4.
4. notify() calls NotifyingQueue.ready(¬ify)
A more simple solution like this was considered:
1. NotifyingQueue.ready(¬ify)
2. NotifyingQueue calls notify(Request)
3. notify() processes, back to 1.
But was decided against because it would cause a stack overflow for fibers,
as a RequestHandler needs to call RequestQueue.ready() and if fibers are
involved that call will be issued from within the fiber.
If ready() calls notify again another processing of a request in the fiber
will happen, causing another call to ready() leading to a recursion.
Now we require that the fiber calls pop in a loop.
Usage example for a hypothetical client who writes numbers to a socket
Boost Software License Version 1.0. See LICENSE_BOOST.txt for details.
Alternatively, this file may be distributed under the terms of the Tango
3-Clause BSD License (see LICENSE_BSD.txt for details).
Queue that provides a notification mechanism for when new items were added
Generic interfaces and logic for RequestQueues and related classes.
Genericly speaking, a request handler delegate is being registered at the queue (ready()). The notifying queue will then call notify() to inform it about a new item added, notify() is expected to call pop() to receive that item. It should keep calling pop() until no items are left and then re-register at the queue and wait for another call to notify(). In other words:
1. NotifyingQueue.ready(¬ify)
2. NotifyingQueue.ready calls notify()
3. notify() calls NotifyingQueue.pop();
* pop() returned a request: notify() processes data, back to 3.
* pop() returned null: continue to 4.
4. notify() calls NotifyingQueue.ready(¬ify)
A more simple solution like this was considered:
1. NotifyingQueue.ready(¬ify)
2. NotifyingQueue calls notify(Request)
3. notify() processes, back to 1.
But was decided against because it would cause a stack overflow for fibers, as a RequestHandler needs to call RequestQueue.ready() and if fibers are involved that call will be issued from within the fiber. If ready() calls notify again another processing of a request in the fiber will happen, causing another call to ready() leading to a recursion.
Now we require that the fiber calls pop in a loop.
Usage example for a hypothetical client who writes numbers to a socket