Okay, there are some naming conventions in this e-mail that make it very
hard to determine what you are talking about. There are thread pools and
child pools, they are not the same thing. A child pool is associated with
a child process, a thread poo is associated with a thread.
> It appears to
On Fri, Jul 13, 2001 at 07:20:26PM -0400, Cliff Woolley wrote:
> Semi-related to this is something I was wondering about this morning when
> I woke up, which is this: what happens if there's a per-thread allocator
> (sms) that's used as the parent of all sms's in that thread, and some
> portion of
> > It appears to me that APR threads (on unix) are automatically creating a
> > subpool, and then later destroying it only if/when apr_thread_exit() is
> > explicitly called. I have a few questions about
threadproc/unix/thread.c:
> >
> > 1) How do we guarantee the child-pool is being destroyed? Wh
On Fri, 13 Jul 2001, Aaron Bannert wrote:
> It appears to me that APR threads (on unix) are automatically creating a
> subpool, and then later destroying it only if/when apr_thread_exit() is
> explicitly called. I have a few questions about threadproc/unix/thread.c:
>
> 1) How do we guarantee the
It appears to me that APR threads (on unix) are automatically creating a
subpool, and then later destroying it only if/when apr_thread_exit() is
explicitly called. I have a few questions about threadproc/unix/thread.c:
1) How do we guarantee the child-pool is being destroyed? What happens
if the
Just to let folks know, I'm off to Havana tomorrow afternoon for a few days
(back Wednesday) and won't be in contact at all! Yes, I'm not even taking
my laptop :)
When I get back I'll try to catch up, but have my 6 monthly check over the
weekend so will be distracted until at least Sunday afterno
After a respectable lunch at Boudin's, Ryan and I think we have the general
answers
to child handles.
The apr_foo_open/create calls need an APR_INHERIT flag bit to mark resources as
inheritable. This offers two advantages;
1. the app doesn't need to worry about fork/exec cleanups v.s. inherit
[EMAIL PROTECTED] wrote:
>
> BTW, the threaded MPM isn't starting up enough child
> processes (only 1). StartServers is 3 - is the count of 3 supposed to
> include the parent and the unixd child?
no, StartServers and the other process related directives don't include
the parent or our
Ciao Sander,
> $ awk -f build/make_export.awk include/apr_sms_threads.h
> APR_HAS_THREADS
> apr_sms_threads_create
> apr_sms_threads_create_ex
> /APR_HAS_THREADS
>
> As you can see this produces the correct output on my
> box. I can't imagine that awk on FreeBSD is generating
> so
> PS. Hiroyuki, could you send me your httpd-2.0/srclib/apr/apr.exports
> please? I'm curious if my thoughts are matching the behaviour on
> your machine.
apr.exports and apr.exports.patched are attached in this mail.
the former is created from apr_sms_threads.h rev 1.1 and the
latter from
Hi Hiroyuki,
I've thought about it some more and tried the following
(in the apr directory _without_ any changes to the
apr_sms_threads.h file):
$ awk -f build/make_export.awk include/apr_sms_threads.h
APR_HAS_THREADS
apr_sms_threads_create
apr_sms_threads_create_ex
/APR_HAS_THRE
> Ok, I'm back to fixing all the 64 bit off_t discrepancies in APR/Apache.
>
> Can we basically agree that a "Bucket" can never be bigger than apr_ssize_t?
Is the bucked backed by RAM? If so, then I agree. file buckets that can be
sent down the chain for
use by sendfile should not have this res
> hi,
>
> The included is a patch which will help you making
> httpd-2.0 successfully on such OSs as FreeBSD.
> Unless applying this patch, the correct apr.exports
> file cannot be created and the make fails when server/exports.c
> is being compiled.
Oh dear, I got bitten by buildexports/make_exp
hi,
The included is a patch which will help you making
httpd-2.0 successfully on such OSs as FreeBSD.
Unless applying this patch, the correct apr.exports
file cannot be created and the make fails when server/exports.c
is being compiled.
cheers,
hiro hanai
Index: apr_sms_threads.h
==
> This means a huge file would need to be split by the caller into multiple file
> buckets, no longer than ssize_t. Is this reasonable?
Wouldn't that make it difficult to call sendfile on a file bucket that
points to a huge file?
Roy
> From: <[EMAIL PROTECTED]>
> Sent: Thursday, July 12, 2001 12:30 PM
>
>
> > stoddard01/07/12 10:30:16
> >
> > Modified:threadproc/win32 proc.c
> > Log:
> > Set the DETACHED_PROCESS creation flag
>
> > * window we are starting in. And we had better redfine our
> >
Ok, I'm back to fixing all the 64 bit off_t discrepancies in APR/Apache.
Can we basically agree that a "Bucket" can never be bigger than apr_ssize_t?
I've no problems with using apr_off_t for the length of a full Brigades itself.
That means we can split a brigade on any apr_off_t, but would only n
From: <[EMAIL PROTECTED]>
Sent: Thursday, July 12, 2001 12:30 PM
> stoddard01/07/12 10:30:16
>
> Modified:threadproc/win32 proc.c
> Log:
> Set the DETACHED_PROCESS creation flag
> * window we are starting in. And we had better redfine our
> * handles for S
> would it be usefull to have some kind of
> 'sms_factory' which you could call
> either with a identifier, or better yet, a set of capabilities it
> requires from the SMS
> (manysmallallocs, realeaseatend ) or ( bigallocs,tracking)
>
> which could then give you the best match for your environmen
19 matches
Mail list logo
