httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject RE: story posted
Date Fri, 07 Feb 2003 01:23:54 GMT
At 06:00 PM 2/6/2003, NAIK,ROSHAN (HP-Cupertino,ex1) wrote:

>Also blaming on use of TLS seems a little strange since use of TLS is
>supposed to improve re-entrancy isn't it ? 

That's something of a misunderstanding... so I'll take a second to offer
an example of the difference.

Thread-safe code assures that no globals get trounced... if a support
function updates a variable 'foo', and several threads are calling the
update function, none of the threads should trust the resulting value
of 'foo' at any given time.  You have no control of the kernel scheduler,
so you don't know when your thread will be interrupted.

Reentrant code is another matter, and occurs at two levels.  Let's take
a simple PHP example, suppose PHP can include a second virtual
page, to which it calls back into Apache to provide.  Apache decides
that page is a PHP page, so it creates another request to PHP and
runs it within the current thread.  PHP may have assumed that the
thread-local variables were safe, but the inner request modifies some
thread-local values and, after returning from the inner, virtual request,
the outer request will discover it's thread-local variables have all been

The other reentrancy issue are system interrupts.  Wherever some
async event or signal occurs, those same 'trusted' thread-local variables
can be corrupted if the signal handler or async event driver calls that
supposedly 'thread safe' code.

So actually, the TLS storage problem ends up as our number one
obstacle to true async design.  Coders presume that replacing all of
their globals with TLS resolved all of the multithreaded issues (as your
post suggests, it's a common misunderstanding.)  So now when we
get Apache 3.0 ready - we discover all of this code that was once
thread-safe really isn't.

And finally, TLS storage is a huge obstacle to ever implementing any
multithreaded, async server that might service some request from
multiple threads.  Such a design might start off the request on one
thread, but as various states of the request occur, the results might
be dispatched from another thread.

In short, TLS storage is really an evil wrapper to eliminate the greater
evil of globals.  It doesn't solve the problem five years from now ;-)


View raw message