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 Tue, 18 May 1999 14:46:38 GMT

I'm am really not sure I follow you.  I agree this function is needed.  I
haven't quite gotten to it.  The original spec was created by taking the
NSPR calls that were made in the apache-nspr repository and determining
what they did.  We never made a call to get the current thread in
apache-nspr.

> There are two syncronization things going on here.
>  1) blocking signals.
>  2) multiplexing the global freelist of large blocks.
> 
> The blocking of signals needs to change.
> 
>    ap_block_alarms(<expression that gets current thread>);
> 
> One of the many dimensions of this context debate is what
>   <expression that gets current thread>
> expression is.  

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.  In 1.3, the only
signals the child dealt with were HUP, TERM, and USR1.  All three signal
handlers checked the value of alarms_blocked (probably not the right
name), and defered what they had to do if we were in the middle of a
critical section.

Because this code is now going into APR, and we are allowing users to set
their own signal handlers, we can't garauntee they will set the equivalent
of alarms_blocked correctly, nor even check when important, so we aren't
going to make them.  Instead, we are basically going to give them the
option of blocking all signals in the critical section, or not depending
on what they are coding.  For example, somebody writing code that will
NEVER be interrupted would not want to block any signals in APR.  Most
people will want to block siganls.

This is not a thread issue!  I still do not understand why you want to say
it is.  This is an issue about how APR functions.  How ALL of APR will
function in the users code.

> 
>    a)  cntx->thread
>    b)  pool->thread
>    c)  ap_current_thread()
> 
> I have been arguing that B is the right awnser.
> 
> I'd like to change my mind.
> 
> I now think C is the right awnser.  Can the advocates of the context
> explain why they would prefer not to have a

I do not think any of the context advocates have said this function isn't
necessary.  If you look at the original or current context implementation,
you will see no mention of threads.  I conceeded to put threads into
contexts at some point in the future when this discussion began, because
you asked me to.  That is the only time threads and contexts were ever
mixed.

> 
>    ap_thread *ap_current_thread(void)
> 
> routine?

I have avoided writing this routine, because I am not sure of the best way
to do it.  I would rather not have a thread table inside of APR, that is
what the OS is for.  I need to determine if just calling pthread_self (or
it's equivalent) is enough, or if it is possible that in the future I
would need to store my own thread info.

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