On Tue, Dec 11, 2001 at 11:27:25AM +0100, Sander Striker wrote:
> A thread doesn't own any pools nor does it know about specific pools,
> the same goes for the other way around.
Actually, there is a pool created and associated to a thread when that
thread is created. See APR_POOL_IMPLEMENT_ACCESSO
> From: Sander Striker [mailto:[EMAIL PROTECTED]
> Sent: 11 December 2001 11:27
> > From: Christian Gross [mailto:[EMAIL PROTECTED]
> > Sent: 11 December 2001 11:19
>
> > At 22:12 04/12/2001 -0500, Cliff Woolley wrote:
> >
> > > > This is my second go at the pools code.
> > >
> > >A potential sna
> From: Christian Gross [mailto:[EMAIL PROTECTED]
> Sent: 11 December 2001 11:19
> At 22:12 04/12/2001 -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
At 22:12 04/12/2001 -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 down the road when we try to im
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
> 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
> 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
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'
Sander Striker wrote:
Hi,
This is my second go at the pools code.
I incorporated some suggestions made by Brian Pane.
Please review,
Sander
PS. The debug code will come back, but in a different
incarnation. I need some time to do that without
making the code unreadable.
Thanks, I'll post som
Hi,
This is my second go at the pools code.
I incorporated some suggestions made by Brian Pane.
Please review,
Sander
PS. The debug code will come back, but in a different
incarnation. I need some time to do that without
making the code unreadable.
apr_pools.c
Description: Binary data
37 matches
Mail list logo
