httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hyde <bh...@pobox.com>
Subject Re: ap_current_thread?
Date Wed, 19 May 1999 14:30:56 GMT
Ryan Bloom <rbb@raleigh.ibm.com> writes:

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

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

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

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

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

 - ben

Mime
View raw message