On Thu, 21 Jun 2001, Bill Stoddard wrote:
> > On 19 Jun 2001, Jeff Trawick wrote:
> >
> > > [EMAIL PROTECTED] writes:
> > >
> > > > The issue of how to deal with restart processes when one thread is stuck
> > > > serving a long-lived request. That was the major reason for not releasing
> > > > 2.0.18 as a beta AFAICR. I posted a design that solves the problem, but
> > > > then other issues got in the way of implementing it. I started the patch
> > > > last Friday, and if I can find a few hours to devote to it, I should have
> > > > a patch this week sometime.
> > >
> > > I guess you're talking about
> > >
> > > Message-ID: <[EMAIL PROTECTED]>
> >
> > Nope. I tend to design by evolution. This message discusses my first go
> > at this design. In later messages on this thread, I explained how it was
> > actually possible to have the temporary process become the real child
> > process.
> >
> > The short story is that when the child process begins to die, the parent
> > spawns a new child. That child starts to create threads, but only creates
> > as many as it can. When it can't create any more, it waits until it can
> > finish creating the rest of it's threads.
> >
> > The code is actually relatively simple, I just haven't had the time to
> > write the code up yet.
>
> Ryan,
> I suggest you hold off writing any code and see what Paul Reder is working on. Paul
>just
> spent some time reviewing his design with Jeff and I and all three of us are
>convinced his
> is the right solution. I am sure we can convince you too but communicating the nitty
> gritty details of the design via e-mail is not going to be simple. Can you fly out to
> Raleigh :-) ? Or perhaps get on a conference call (I can set up a call in number) so
> sother folks can partcipate?
Bill,
I will finish my code. My design should take under 100 lines of changes,
and requires no linked lists in shared memory. I have reviewed the design
that Paul has detailed, and I disagree that it is correct. It will
require locking anytime somebody wants to walk the scoreboard, which means
that potentially the scoreboard will be run once a request. Think
mod_status and/or mod_snmp.
I look forward to Paul's code, but I disagree that his design will work.
Ryan
_______________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
