* On 2001-12-04 at 18:00,
Jeff Trawick <[EMAIL PROTECTED]> excited the electrons to say:
>
> Please try this patch and post
It has fixed my problem; I'll get you the details you
requested to-night or to-morrow. Thanks!
--
#kenP-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
On Wed, Dec 05, 2001 at 06:23:05PM -, [EMAIL PROTECTED] wrote:
>...
> +AC_DEFUN(APU_CHECK_DB2,[
> +apu_found_db=0
> +AC_CHECK_HEADER(db2/db.h, [
> AC_CHECK_LIB(db2, db_open, [
> apu_have_db=1
> + db_header=db2/db.h
> + db_lib=db2
> + db_version=2
> + apu_found_db=1
>
On Wed, Dec 05, 2001 at 10:14:20AM -0800, Aaron Bannert wrote:
> No, it'll be something like this:
>
> #ifdef APR_HAS_THREADS
> /* do stuff to prevent deadlocks on threaded builds, like: */
> apr_thread_mutex_lock(mutex);
> #else
> /* I can't imagine what you'd need to do special to tr
On Wed, Dec 05, 2001 at 06:06:28PM +0100, Sander Striker wrote:
> > IMHO, I don't see the use of a macro for this kind of thing in the first
> > place, because it's a simple enough construct. Also, we might want to check
> > for errors on that lock call (up to you).
>
> For one, use of this macro
Justin Erenkrantz writes:
> Highlights:
>
> - Split out DB2 and DB3 detection since they are no longer related
> (as DB3 only has db_create and DB2 has db_open). Was db_open in
> any released version of DB3?
AFAIK, 3.0.55 was the first released DB3, and it didn't have db_open.
> - Ch
> From: Aaron Bannert [mailto:[EMAIL PROTECTED]
> Sent: 05 December 2001 17:32
> On Wed, Dec 05, 2001 at 12:35:00PM +0100, Sander Striker wrote:
> > >
> > > Ack. No. Declare a new scope like so:
> > > #define UNLOCK(mutex) \
> > > do { \
> > > if (mutex) \
> > > apr_thread_mutex_u
The original code was 100% correct. It is the model that we use
through out the code, and it is the model that we should continue
to use. It allows people to do
UNLOCK(mutex);
which is what most programmers expect.
Ryan
On Wednesday 05 December 2001 08:44 am, Brian Pane wrote:
> Aar
At 11:44 AM 12/05/2001, Brian Pane wrote:
Aaron Bannert wrote:
On Wed, Dec 05, 2001 at 12:35:00PM +0100, Sander Striker wrote:
Ack. No. Declare a new scope like so:
#define UNLOCK(mutex) \
do { \
if (mutex) \
apr_thread_mutex_unlock(mutex); \
} while(0)
Calling it like UNLOCK(mutex)
Aaron Bannert wrote:
On Wed, Dec 05, 2001 at 12:35:00PM +0100, Sander Striker wrote:
Ack. No. Declare a new scope like so:
#define UNLOCK(mutex) \
do { \
if (mutex) \
apr_thread_mutex_unlock(mutex); \
} while(0)
Calling it like UNLOCK(mutex) (i.e. no semicolon) is just badness
and wi
Sander Striker wrote:
So, actually, there isn't much difference between the plain apr_pcalloc
implementation and the apr_pcalloc macro? (other than code duplication)
The real solution seems to be eliminating apr_pcalloc calls when possible
(and sensible). Maybe we can have another quantify run to
On Wed, Dec 05, 2001 at 12:35:00PM +0100, Sander Striker wrote:
> >
> > Ack. No. Declare a new scope like so:
> > #define UNLOCK(mutex) \
> > do { \
> > if (mutex) \
> > apr_thread_mutex_unlock(mutex); \
> > } while(0)
> >
> > Calling it like UNLOCK(mutex) (i.e. no semicolon) is
> From: Ryan Bloom [mailto:[EMAIL PROTECTED]
> Sent: 05 December 2001 15:42
> On Wednesday 05 December 2001 03:35 am, Sander Striker wrote:
[...]
>> Damn, I really need to find a way for me not to hit that
>> tab key. Sorry about that, force of habbit that is a)
>> hard to change (working on it t
On Wednesday 05 December 2001 03:35 am, Sander Striker wrote:
> > From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]
> > Sent: 05 December 2001 03:56
> >
> > On Fri, Nov 30, 2001 at 06:27:14PM +0100, Sander Striker wrote:
> > > Hi,
> > >
> > > This is my second go at the pools code.
> > > I incorpor
> On Wed, 5 Dec 2001, Sander Striker wrote:
>
> > Right, ok. The 8192 was a number used in the original pools code,
> > I just ripped it :). The BOUNDARY_SIZE is set to be 4096, which
> > is the size of a page on most systems.
>
> i recall doing some statistics gathering and trying to get a sin
[thanks for the bcc, sander]
On Wed, 5 Dec 2001, Sander Striker wrote:
> Right, ok. The 8192 was a number used in the original pools code,
> I just ripped it :). The BOUNDARY_SIZE is set to be 4096, which
> is the size of a page on most systems.
i recall doing some statistics gathering and try
Hi,
This is the 3rd round of the pools rewrite. This time I have gotten
rid of all tabs (grmpf) and followed some suggestions by Justin.
I'm reposting the whole file instead of a diff, since this is
the first time it is posted inline. Hopefully the interested lot
out there have an easier time l
> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]
> Sent: 05 December 2001 04:25
> On Tue, Dec 04, 2001 at 10:12:20PM -0500, Cliff Woolley wrote:
> >
> > > This is my second go at the pools code.
> >
> > A potential snag with the thread-specific pools idea was brought up today
> > when I was t
> From: Roy T. Fielding [mailto:[EMAIL PROTECTED]
> Sent: 05 December 2001 04:20
> On Tue, Dec 04, 2001 at 10:12:20PM -0500, Cliff Woolley wrote:
> >
> > > This is my second go at the pools code.
> >
> > A potential snag with the thread-specific pools idea was brought up today
> > when I was tal
> From: Cliff Woolley [mailto:[EMAIL PROTECTED]
> Sent: 05 December 2001 04:12
>> This is my second go at the pools code.
>
> A potential snag with the thread-specific pools idea was brought up today
> when I was talking with FirstBill and some of the others. What is this
> going to do to us a l
> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]
> Sent: 05 December 2001 03:56
> On Fri, Nov 30, 2001 at 06:27:14PM +0100, Sander Striker wrote:
> > Hi,
> >
> > This is my second go at the pools code.
> > I incorporated some suggestions made by Brian Pane.
> >
> > Please review,
>
> General
Aaron Bannert wrote:
On Tue, Dec 04, 2001 at 06:56:11PM -0800, Justin Erenkrantz wrote:
[...]
2) It probably needs to be modified to use the new locking API.
I don't see this as a showstopper, but I think it's something
that should happen and may help with the locking performance.
Aaron can s
On Tue, Dec 04, 2001 at 06:56:11PM -0800, Justin Erenkrantz wrote:
[...]
> 2) It probably needs to be modified to use the new locking API.
>I don't see this as a showstopper, but I think it's something
>that should happen and may help with the locking performance.
>Aaron can speak more
Cliff Woolley wrote:
Okay. The situation (real or imagined) I was leery of was not allocation
but pool destruction... what happens when you have a subpool of a
one-thread-at-a-time pool that was created in one thread and gets
destroyed in another pool, if the parent pool is still active in the oth
On Tuesday 04 December 2001 07:53 pm, Bill Stoddard wrote:
> > Cliff Woolley wrote:
> > >>This is my second go at the pools code.
> > >
> > >A potential snag with the thread-specific pools idea was brought up
> > > today when I was talking with FirstBill and some of the others. What
> > > is this
Bill Stoddard wrote:
[...]
If a future async implementation has this same property--i.e.,
pools can be "passed" from one thread to another, but a given
pool can only have its methods invoked from one thread at a
time--then we shouldn't have any problems.
--Brian
What happens if a thread exits (unde
> On Tue, Dec 04, 2001 at 10:12:20PM -0500, Cliff Woolley wrote:
> >
> > > This is my second go at the pools code.
> >
> > A potential snag with the thread-specific pools idea was brought up today
> > when I was talking with FirstBill and some of the others. What is this
> > going to do to us a
> From: "Cliff Woolley" <[EMAIL PROTECTED]>
> Sent: Tuesday, December 04, 2001 9:12 PM
>
>
> > > This is my second go at the pools code.
> >
> > A potential snag with the thread-specific pools idea was brought up today
> > when I was talking with FirstBill and some of the others. What is this
> >
> Cliff Woolley wrote:
>
> >>This is my second go at the pools code.
> >>
> >
> >A potential snag with the thread-specific pools idea was brought up today
> >when I was talking with FirstBill and some of the others. What is this
> >going to do to us a little ways down the road when we try to impl
On Tue, 4 Dec 2001, Brian Pane wrote:
> I think there's an easy answer.
>
> The thread-specific pools in this implementation are really
> just pools that happen to own their own free lists.
>...
>
> If a future async implementation has this same property--i.e.,
> pools can be "passed" from one thr
Highlights:
- Split out DB2 and DB3 detection since they are no longer related
(as DB3 only has db_create and DB2 has db_open). Was db_open in
any released version of DB3?
- Check for db[23]/db.h and db[23] to be nicer about detecting
platforms that have this combination.
And, this remove
From: "Cliff Woolley" <[EMAIL PROTECTED]>
Sent: Tuesday, December 04, 2001 9:12 PM
> > This is my second go at the pools code.
>
> A potential snag with the thread-specific pools idea was brought up today
> when I was talking with FirstBill and some of the others. What is this
> going to do to
On Tue, Dec 04, 2001 at 10:12:20PM -0500, Cliff Woolley wrote:
>
> > This is my second go at the pools code.
>
> A potential snag with the thread-specific pools idea was brought up today
> when I was talking with FirstBill and some of the others. What is this
> going to do to us a little ways do
On Tue, Dec 04, 2001 at 10:12:20PM -0500, Cliff Woolley wrote:
>
> > This is my second go at the pools code.
>
> A potential snag with the thread-specific pools idea was brought up today
> when I was talking with FirstBill and some of the others. What is this
> going to do to us a little ways do
Cliff Woolley wrote:
This is my second go at the pools code.
A potential snag with the thread-specific pools idea was brought up today
when I was talking with FirstBill and some of the others. What is this
going to do to us a little ways down the road when we try to implement
async I/O, and all of
> This is my second go at the pools code.
A potential snag with the thread-specific pools idea was brought up today
when I was talking with FirstBill and some of the others. What is this
going to do to us a little ways down the road when we try to implement
async I/O, and all of the sudden reque
On Fri, Nov 30, 2001 at 06:27:14PM +0100, Sander Striker wrote:
> Hi,
>
> This is my second go at the pools code.
> I incorporated some suggestions made by Brian Pane.
>
> Please review,
General comments:
1) Lose the tabs.
2) It probably needs to be modified to use the new locking API.
I don'
Justin Erenkrantz wrote:
On Tue, Dec 04, 2001 at 04:35:01PM -0800, Brian Pane wrote:
Some test results, thanks to Ian H.:
http://webperf.org/a2/v30/
This compares today's httpd-2.0 CVS head with
my "recycle pools" patch for the worker MPM and
Sander's new implementation of pools.
Sander's pool cod
Ryan Bloom wrote:
On Tuesday 04 December 2001 07:53 am, Stas Bekman wrote:
We don't have tell() yet. Nobody has needed it before, but we did
need seek(). Feel free to implement it, or I will do so later this
week.
Thanks Ryan!
I cannot find anything that implements the tell() functionality in A
On Tue, Dec 04, 2001 at 04:35:01PM -0800, Brian Pane wrote:
> Some test results, thanks to Ian H.:
> http://webperf.org/a2/v30/
> This compares today's httpd-2.0 CVS head with
> my "recycle pools" patch for the worker MPM and
> Sander's new implementation of pools.
>
> Sander's pool code yielded
Some test results, thanks to Ian H.:
http://webperf.org/a2/v30/
This compares today's httpd-2.0 CVS head with
my "recycle pools" patch for the worker MPM and
Sander's new implementation of pools.
Sander's pool code yielded a substantial drop
in usr CPU consumption (see the "cpuu" links on
the tes
40 matches
Mail list logo