httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zeev Suraski <z...@zend.com>
Subject Re: work in progress: mpm-3.tar.gz (fwd)
Date Sat, 19 Jun 1999 23:41:36 GMT
At 00:13 20/06/99 , Dean Gaudet wrote:
>On Sat, 19 Jun 1999, Rasmus Lerdorf wrote:
>
> > > > Hrm, when I first read Dean's description, I thought about this 
> too, but
> > > > figured we wouldn't have a problem because we really just have a single
> > > > entry point.  Our only other hook is the config stuff and we don't do
> > > > anything that I think would require it to be done from the same thread.
> > > > However, I could see this restriction being a pain if we wanted to 
> be able
> > > > to enter PHP from more that just the content-handling request phase.
> > > > I would think this would be a big problem for mod_perl stuff.
> > >
> > > It does affect us.  We change the configuration directives for the 
> current
> > > thread and expect them to take affect when the PHP callback is called;
> > > Under these restrictions, we can't really do it.
> >
> > Hrm..  True, and we store it TLS-style keyed on the thread id.  How the
> > heck is it useful to have a module's init handler be in a separate thread
> > from the actual invocation later on?  Well, ok, the answer was already
> > given, and that is to use Apache's memory pool mechanism to store things.
> > We can abstract that away in SAPI, I guess, but 3rd party things that
> > don't know about Apache's memory management mechanism and do TLS-style
> > things to be thread-safe are going to be confused.  So yes, I agree with
> > you, it would be a PITA for us.
>
>I really don't understand the difficulty.
>
>I return to my earlier example:
>
>     FILE *f = fopen("foo", "r");
>
>You may now use f in any thread.  There's no requirement that f be used
>only in the thread which created it.  I don't see why such a requirement
>is necessary!  If libc didn't keep everything it needed to know in the
>structure pointed to by f, why does it have a structure to begin with?
>
>Now, you're complaining about TLS.  Apache knows nothing about TLS.
>It won't know anything about it until that mythical portable run-time
>appears.  It's not like I'm breaking anything, there's nothing to break.

Other modules use TLS though, regardless of Apache, and expect some sort of 
a continuous execution model, where each part of the execution phase occurs 
within the same thread.  For example, the PHP MySQL module defines a global 
structure where it stores information that's used in all of its 
functions.  A pointer to that structure isn't passed between all of the 
functions, since some of them are called from PHP's engine, that knows 
nothing about the MySQL module's globals.

In a multithreaded environment, obviously, you can't really have a global 
structure like that, but you need to pick some TLS-style alternative.  So, 
when you compile PHP 4.0 as thread safe, it accesses that structure using 
the thread safe resource manager.  Notice that the MySQL module doesn't 
know and doesn't need to know that it's running within Apache - all of its 
interface with the outside world is done through PHP's API functions, which 
may wrap around Apache, ISAPI or plain old libc for the CGI binary 
version.  It doesn't know about request_rec or any server-side 
structures.  The only thing it expects is that the execution model is 
linear, and occurs within the same thread.

PHP interfaces with Apache in two stages - configuration directive parsing 
and the actual scripting execution callback.  Lets assume these two are 
called in separate threads.

PHP's configuration parsing mechanism, in this case, reading from 
.htaccess/.conf files using registered Apache callbacks, stores those 
directives in PHP dynamic structures that use PHP's memory manager.  PHP's 
memory manager, in turn, uses TLS.

Since the data structures that were allocated in the configuration parsing 
phase are used on another phase (script execution) - their deallocation may 
occur in a different thread from that in which they were 
allocated.  Undoubtfully, that would cause problems since the TLS structure 
used by the memory manager for deallocation won't be the right structure.

Now, I understand your point more or less.  What I'm saying is that such a 
restriction is very aggressive and somewhat unnatural, and is likely to 
cause a lot of headache to module developers.  In PHP, it would be possible 
to get around it by moving the TLS code into a separate DLL/.so that would 
be server dependent, and would be implemented as standard TLS for all web 
servers except for apache, and implement it as request-local-storage in 
Apache.  It would be a pain, though, so if you could keep a background task 
to think about how to allow modules to ask for all of their execution path 
to occur within the same thread (without preventing the whole server from 
using asynchronous operations), it would be great.

Zeev
--
Zeev Suraski   <zeev@zend.com>  http://www.zend.com/
For a PGP public key, finger bourbon@netvision.net.il

Mime
View raw message