httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: Context types in APR.
Date Fri, 07 May 1999 16:10:18 GMT
> Can one of the advocates of this - add another parameter
> for 'stuff' to every APR function - please respond to
> my questions.

First of all, we MUST add a parameter to every apr function regardless of
whether it is a context or a pool.  The reason for this, is that we do not
want to rely on malloc/free to allocate memory.  Right now, contexts have
a pool in them, so this takes care of this.  I would love to say the
context/pool only needs to be sent to functions that allocate memory, but
I don't know what other platforms will require in the way of helper
structures, so although I could limit the passing to functions that need a
pool in UNIX, what about OS/2, windows, etc..

> 1. Is blocking signals an operation on threads, and if
>    so why would it's state be better in the context 
>    rather than the thread's state.

It really isn't a thread operation.  Blocking signals MAY be necessary in
non-threaded programs to keep other processes from interupting that
function.  It is more an operation on apr than an operation on threads.

> 2. What compelling advantage is worth the cost of 
>    passing an additional parameter to every function?

As I said above, allocating memory requires this parameter.  I could put
it only in the paremeter list to the creation function, and then store the
pool pointer in the structure, but I don't believe this allows for the
flexibility for future growth that contexts do.

> 3. Do pools need to block signals?  If so, do they
>    need a pointer to the thread they reside in?

Pools do need to be able to block signals, at least in some places.  They
do not need a pointer to the thread they reside in though.  The thread is
unnecessary, and what do we assign the pointer to in a non-threaded case?
Proof to these two answers can be found in 1.3.X tree of Apache.  We call
block_alarms and unblock_alarms in the pool code.  This increments a
variable, and when we get a signal, we check that varible.  This is on a
NON-THREADED server, so it seems to me that either we are wasting cycles,
or this is a needed ability (Or, I haven't reviewed the code thoroughly



View raw message