Folks, As of right now, the stability patch is, I believe, *nearly* "good enough."
Something occurred to me, though, as I considered the interactions of classes implementing RyuApp. A given handler, in a given RyuApp, is acting in response to a *single* event that has been consumed from the events queue for that RyuApp. If that same execution of a handler *generates* events internally (say, for example, an EventOFPStateChange or any of the EventDP* family from dpset.py), it seems possible that a deadlock could occur between two RyuApps. Consider the following hypothetical situation: - RyuApp A has a full event queue (128 items of 128 available slots), is switched to, and begins to process its event queue. - RyuApp A consumes 1 event (queue has 127 events) - The handler RyuApp A executes creates an event observed by RyuApp B, and attempts to send it. - RyuApp B *also* has a full event queue (128 items of 128 available slots). - RyuApp A's handler blocks on trying to send the event to RyuApp B. - RyuApp B is switched to, and begins to process its event queue. - RyuApp B consumes 1 event (queue has now 127 events) - The handler RyuApp B executes is written to send *3* events observed by RyuApp A, which it attempts to send one after the other. - The first event RyuApp B generates does not block on send, but fills RyuApp A's event queue (128 items). - The second event RyuApp B generates blocks the handler. - RyuApp A is now switched to, completes the execution of its handler by sending the event it was waiting to send to RyuApp B (which now fills RyuApp B's event queue to 128 items). - RyuApp A consumes another event (queue is now at 127 items), runs the same handler that generates an event for RyuApp B, and blocks (because RyuApp B's event queue is full). - RyuApp B is switched to, and the second of the 3 events is sent to RyuApp A (thereby filling its event queue to 128 items). - RyuApp B now tries to send the third of the 3 events, and blocks because RyuApp A's event queue is full. - RyuApp A, however, is cannot be switched to - because it is still waiting for RyuApp B's event queue to have an open slot. An open slot, however, did not appear, because RyuApp B was still executing the same handler, and had not had a chance to consume a new event from its event queue. It seems to me that bounded queues for events in RyuApp, when one RyuApp can *generate* new events to send to another, are a recipe for difficult-to-detect deadlock conditions when there are large numbers of events. I am wondering if RyuApp event queues should either be: 1) unlimited, or 2) able to grow, in a stepwise fashion, without a size bound - but logging on each size increase. The concern, of course, is unbounded memory consumption, with an unbounded event queue. The mirroring concern, for a bounded event queue, is the potential for deadlock. I am inclined to suggest that the prospect of deadlock is a greater concern, and that stepwise growth (with a log message issued at each increase) is a better solution. If I am misunderstanding something, please let me know. Otherwise, I welcome your thoughts on the above. If my proposed solution meets with your approval, I will remove the semaphore in app_manager.py, and will replace it with an event queue that does not block on put(), but that instead doubles in size whenever it is full (and logs that the resize occurred). Best, Victor -- Victor J. Orlikowski <> vjo@[cs.]duke.edu ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Ryu-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ryu-devel
