httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@raleigh.ibm.com>
Subject Re: ap_current_thread?
Date Wed, 19 May 1999 14:38:46 GMT

> > Two different flags.  One flag in the context is for being signal safe,
> > another is for being cancellation safe.  IMHO, when we are in a section
> > of code like this one, we just disallow cancellation of this thread, or
> > signals.
> 
> I assume by "cancellation of this thread" you mean thread's pool cleaups
> are run via to ap_destroy_pool and the thread is then destroyed.

Yes.  There is a function in pthreads that lets me hook into it's cleanup
stack.  I keep meaning to put that code in, but I also keep forgetting.
I'll get to it soon, I promise.  Basically, whenever the thread goes away,
the VERY last thing it will ALWAYS do is a cleanup of it's own pool.  This
will be accomplished with pthread_cleanup_push in the pthread
implementation, and I am assuming that other thread impl's have similar
functions.

> 
> What do you mean by "signal" is that a thread or a process operation -
> why is it per context?

signal is a UNIX signal.  In it's cleanest form, it is a process
operation, but once you add threads into the picture, you also have the
ability to signal any thread within the process.  If the signal is coming
from within the same process, you CAN (with pthread_kill), but don't have
to,  signal a specific thread.  If the signal is coming from another
process (using kill of killpg), it is undefined which thread gets the
signal.  There is no way of knowing in advance which thread will get the
signal, unless only one thread is listening for the signal.  On Linux,
this isn't quite true, but it's close.  It is per context for the precise
reason that it is allowed on both a thread and/or a process.  I can 
block signals for just this thread, or just this process, or all
threads within this process, or all process, or any combination of the
above.

In my mind, this makes it bigger than threads or processes, and that makes
it a context issue.

> > We don't actually have to pass a thread pointer down to
> > ap_block_alarms, because we only care about the current thread.  The OS
> > takes care of figuring out which thread we mean.
> 
> Agreed, in fact you don't need it in the context either.

I am confused.  The message about ap_current_thread made it look like you
were advocating:

ap_block_alarms(ap_current_thread())

I would rather not have a current thread pointer in the context type.  I
would like the context type to have a pool, some flags for APR's use, and
a place for the user to store some data if they desire.  That's it.  If we
find more stuff to put into the context later, so be it.  I am having a
hard time figuring out where else to put these APR flags if not in a
context.  I could put them in the process/thread types, but then the user
would have to specify them multiple times.  I could put them in the pool,
but they have nothing to do with a pool (except that the pool code will
use them), and this seems like a HUGE hack to me.  Contexts make the most
sense for this , IMHO.

> No long jump - it is the easiest design to agree on.  So be it.

Hey, does this mean we are coming close to an agreement??? :)

Ryan

_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	



Mime
View raw message