On Tue, 2007-07-24 at 15:24 +0200, Henrik Nordstrom wrote:
> On mån, 2007-07-23 at 17:01 -0600, Alex Rousskov wrote:
>
> > I may be doing that, but I do not know what a "primary" event is.
>
> The event loop separates the event engines in "secondary" and "primary".
> A numberof secondary, and one primary. The primary event loop is the
> comm select loop.
Understood.
> > BodyPipe and ICAP code may schedule several zero-delay events in a row.
> > In fact, they do that often. If that is not supported, I would have to
> > add such support because rewriting the code to avoid such "chains" seems
> > both difficult and "wrong".
>
> Then you would be bitten by this indeed.
>
> It's a bug. For 3.0.STABLE1 lets patch over the bug by never stopping
> the event loop for an significant amount of time, but should be fixed.
Agreed. I am happy to be responsible for the rewrite after 3.0 release.
> > We can and should fix all that, but hopefully we can leave with 10msec
> > default for now. A proper/complete fix may not be trivial.
>
> Quite likely the fix is trivial, but it will take a bit of time to
> understand the problem in full...
>
> And the 10ms workaround is sufficient to keep things flowing nicely.
I agree that the quick fix is probably trivial but
(a) its side effects are likely to be difficult to grasp in this
over-engineered code (just like the original one-line change).
(b) the overall design can and should be significantly improved
(including making it simpler)
I think using a 10msec workaround (i.e., the original code) is the right
way to go until v3.0 is released.
Thank you,
Alex.
Received on Tue Jul 24 2007 - 08:19:10 MDT
This archive was generated by hypermail pre-2.1.9 : Wed Aug 01 2007 - 12:00:06 MDT