httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <...@engelschall.com>
Subject Re: AAP patch for 2.0a6 available
Date Thu, 31 Aug 2000 16:18:35 GMT

In article <200008281920.MAA97816@trudge.engr.sgi.com> you wrote:
>> This is pretty cool.

> [...]
>> this. Then, Apache could have a
>> --with-threads=(pthread|pth|statethreads) configure option.
> 
> Unless I greatly misunderstand you, I think such a wrapper is not
> possible.  One of the main features of state threads is that they are
> nonconcurrent and nonpreemptive, unlike pthreads.  

BTW, please keep in mind that Pthreads is just an API and the Pthread
specification doesn't force the implementation to be preemptive or
nonpreemptive. Pth is as much Pthreads as for instance LinuxThreads is
Pthreads. So the wrapper approach and --with-threads=(pthread|pth) _IS_
possible, of course.  

But it is correct in this context that because ST doesn't provide a Pthread
API, the --with-threads=statethreads is not really possible with the existing
Pthread based MPMs, of course.

>This is a key
> property of state threads that makes them easier to program and debug
> and also faster than pthreads.  For instance, in the STM I can write
> statements like:
>         global_hit_counter++;
> and use library functions like ctime(), readdir(), and gethostbyname()
> that rely on static buffers, without worrying about race conditions.
> [...]

<grin> Yes, that's exactly why Pth intentionally uses non-preemptive
threading, too ;) It avoids a lot of mutex fiddling and the requirement for a
vendor supplied reentrant libc. Unfortunately most people ignore these issues
when it comes to multithreading and make their life more complicated than it
has to be IMHO...

> With pthreads I must instead write:
>         pthread_mutex_lock(global_hit_counter_mutex);
>         global_hit_counter++;
>         pthread_mutex_unlock(global_hit_counter_mutex);
> and use ctime_r(), readdir_r(), and gethostbyname_r().  The STM has no
> mutex locks in it at all so "porting" it to use pthreads would be a
> nontrivial effort.  I don't know enough about Pth to comment on it, but
> others on the state threads mailing list do.

Pth can be used with any application which is coded against the Pthread API.
The only functionality which is missing is the support for shared memory based
mutexes (for inter-process synchronization) -- but this functionality is
missing also in LinuxThreads, FSU Pthreads, MIT Pthreads, etc. In the past I
was even successful in running Apache 2.0 & dexter with Pth.  Only the accept
mutex stuff was a problem, because of bad assumptions in the Apache code
(remember: it used non-thread aware functions like fcntl() or flock() which
only block only the current thread in a MT environment if the threads are
kernel threads as it is the case in LinuxThreads).

                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

Mime
View raw message