httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hyde <bh...@pobox.com>
Subject Re: Context types in APR.
Date Fri, 07 May 1999 17:06:17 GMT
Ryan Bloom <rbb@raleigh.ibm.com> writes:

> > 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..

No?  It would seem to me that you only need to pass a pool
to those functions that create objects for the API.  For example

    obj = apr_obj_create(p, ...);

Operations that return fresh data structures should always take
an explicit pool since the caller should decided what pool they
belong in.

The case, I assume, your concerned with is when the operation
needs scratch space to work in, but that is not returned to
the caller.  Apache's standard solution to that has been to
store a pool in the object, when it's created, for such things.

That design pattern, the one that means we do r->pool a lot,
works.  I don't see any reason to change it.  Changing it
will ripple thru everything.

Partially as an aside, I'll point out that I often use this
cliche.

   ap_pool *scratch_pool = ap_make_sub_pool(obj->pool);
   ...
   ap_destroy_pool(scratch_pool);

I.e. there is free operation in the pool abstraction.

> > 
> > 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.

Well even "non-thread" programs have a single thread.  Threads are stacks,
and signals are directed at stacks - right?  If we do the work to allow
the thread handling a request to be interupted when we believe that's
the right thing to do.  Work that requires a great deal of care.  Then
clearly we will want to interupt/signal/unwind as an operation on 
individual threads.

> It is more an operation on apr than an operation on threads.

This is the context in it's role as "globals" right?
If you need a data structure to hold state that is "Mr. Apr"
that's ok by me, but I don't think you need to pass it to
every routine.  The routines are operations on objects, and
those objects can have back pointers to the data structures
they reside in  them when they happen to need that.

> > 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, 

Yes, that's what I think we have been doing and I don't see why it's
a broken design.

> but I don't believe this allows for the
> flexibility for future growth that contexts do.

Still yearning for something that get's be excited enought to want to
change from the current approach.

> > 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?

In the non thread case the number of threads doesn't go to zero it goes
to one - you assign it to that thread.

Pools reside in threads.  If two threads wish to share a single pool they
must multiplex their access.

> 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
> enough).

This is the correct reading of the code.  It reflects the fact that in that
server we made no attempt to direct signals at individual threads.  

The desire (possible hopeless) that we can enable the interupting of
the threads handling requests to put them out of their misery in some
carefully crafted but oh so common situations makes it very desirable
to move that counter from a global into the thread data structure.

This would be done, persumably, by having stating a default
presumbably accepting_signals for the request handling threads.
Modules could then override this when they are unable to implement
signal handling in a reasonable way.  We might even put flags in the
module struct to advise the module hook invoking routines how to
establish the blocking state during the calls backs.

> 
> HTH,
> 
> Ryan

 - ben

Mime
View raw message