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 13:38:28 GMT
> > I don't understand why ap_block_alarms needs the current thread.
> > ap_block_alarms is used to make sure that we aren't going to be
> > interrupted by receiving a signal while in this code.
> 
> I thought we had decided to attempt to provide for
> canceling/interupting, etc. individual threads so that in at least
> some cases we could terminate with prejudice threads that seem to have
> gone astray.  I'm right about that, arn't I.

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

> 
> If threads are never: unwound, canceled, interupted, or signaled then
> there is no need an API on the thread to manage if that
> unwinding/canceling/interupting/signalling is enabled/disabled at any
> given moment.

I do not believe we will be doing any longjmp's within threads.  As far as
I know, this is a very dangerous operation, and it is not recommended.  I
know the current state of the hybrid server has no setjump or longjmp
calls in it, and we took great care to make sure they aren't needed.

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