On Wed, Oct 10, 2001 at 11:59:19PM -0400, [EMAIL PROTECTED] wrote: > > On 04-Oct-2001 Rocco Caputo wrote: > > On Wed, Oct 03, 2001 at 09:00:49PM +0200, [EMAIL PROTECTED] > > wrote: > > Paused events will complicate the queue and dispatch logic. For now > > I'm experimenting with pausing the event generator instead. From this > > point of view, it looks like a simpler flow control issue. Is it too > > simplistic, though? What problems have I overlooked? > > Wouldn`t a paused event just go on the end of the queue? Or would this be > wasteful, as events get pulled off, barriered, pushed back on etc etc.
I made a mistake, sorry. Barriers are helpful but only for serializing events. They cannot be used as flow control mechanism directly. You can pause the wheel's select, but you cannot stop a session from posting events without pausing the whole sessions or marking event handler groups as can-send-event-xyz. So we still don't have a solution for consumer-producer flow control. It lacks in information about these relationships. We can't generate it on the fly as we don't have preemptible handlers. But one could declare the path data takes: wheel -> session a -> session b declare a->b and wheel->a if a consumer (b or a) remains in a locked state, lock the producer as well if locks are released, check the producers as well Something like that. It's not really easy to do this right and maybe it doesn't fit into core POE, but a lot of problems are producer-consumer problems or can be modelled as such. Torvald
