On Tue, 10 Jul 2001, dean gaudet wrote:
> On Sun, 8 Jul 2001, Roy T. Fielding wrote:
>
> [clean_child_exit]
> >
> > It is only called when the child exits and not per-thread. I think the
> > threads are already dead by that point, or locked-up due to some fatal
> > error that is the reason why cl
On Sun, 8 Jul 2001, Roy T. Fielding wrote:
[clean_child_exit]
>
> It is only called when the child exits and not per-thread. I think the
> threads are already dead by that point, or locked-up due to some fatal
> error that is the reason why clean_child_exit is being called.
when you say "the thr
On Sun, Jul 08, 2001 at 10:36:10PM -0700, Roy T. Fielding wrote:
> OTOH, it seems the new sms code just needs a whack upside the head to
> stop it from asking for extra memory from its parent.
*cackle*.
just got in, saw a whole boat-load of messages about sms [grief,
who'd have thought it, neh?
On Sun, Jul 08, 2001 at 11:23:56PM -0700, dean gaudet wrote:
> On Sun, 8 Jul 2001, Roy T. Fielding wrote:
>
> > The last time I looked at the pool code it was bogus because
> > clean_child_exit
>
> how can clean_child_exit ever hope to work in a multithreaded server
> without async notification?
On Sun, 8 Jul 2001, Roy T. Fielding wrote:
> The last time I looked at the pool code it was bogus because clean_child_exit
how can clean_child_exit ever hope to work in a multithreaded server
without async notification?
in particular, what happens when modules start creating their own thread
poo
> ok studying the mpm threaded.c code i see that we give each thread a
> sub_pool of pchild. but i think the following patch would be safe,
> because each thread won't exit until it has done its own cleanup.
The last time I looked at the pool code it was bogus because clean_child_exit
assumed eve
so while hacking up that patch to eliminate the block_freelist i thought i
could also get rid of the alloc_mutex entirely. but it appears that
currently the pool code sort of supports multithreaded access to the same
pool.
i say "sort of" because cleanups don't support multithreaded access -- no
