Re: [PHP-DEV] Re: NSPR (was Re: rewritelog inefficiency) (fwd) From: Alex Belits (abelits <email protected>)
Date: 04/29/98

On Wed, 29 Apr 1998, Rasmus Lerdorf wrote:

> An interesting exchange between Dean Gaudet on the Apache team and Wan-Teh
> from Netscape responsible for Netscape NSPR threading implementation.
>
> ---------- Forwarded message ----------
> Date: Wed, 29 Apr 1998 12:36:42 +0800
> From: Wan-Teh Chang <wtc <email protected>>
> Reply-To: new-httpd <email protected>
> To: new-httpd <email protected>
> Subject: [PHP-DEV] Re: NSPR (was Re: rewritelog inefficiency)
>
>
>
> Dean Gaudet wrote:
>
> > On Tue, 28 Apr 1998, Wan-Teh Chang wrote:
> >
> > > In NSPR, every fd that represents a socket or pipe on Unix is put innonblocking
> > > mode (O_NONBLOCK flag is on).
> >
> > Oh wow. Even when you're using pthreads only? This seems inefficient.

[ NSPR threads and nonblocking ]

  As a developer of another HTTP server -- fhttpd -- I can only comment
that I have spent a lot of effort to isolate the processing model of the
server and the processing model of its modules.

  Apache uses multiple processes that do blocking i/o, and PHP when
compiled as a module is linked with them, thus having no need in
either nonblocking i/o or thread-safety. This model is very efficient
(unless the modules cause unreasonable processes bloat), however it may be
possible to achieve more on some systems with significant difference in
overhead for context switch between processes and one between threads in
one process, so they are trying to develop thread-based server. Another
reason for that is an impossibility of using the Apache model in Windows
NT.

  fhttpd is designed using different model -- the main server process is
nonblocking, and it avoids all kinds of operations that may block or take
significant time in the processing loop. The work other than parsing
and rewriting requests, managing connections and handling other processes
however is done in separate processes that can be blocking or nonblocking,
threaded or non-threaded (however the library, I use isn't thread-safe, so
threaded programs will need to support fhttpd protocol using something
else). PHP, naturally, is used in blocking i/o mode with multiple
processes, so it "see" things pretty much like Apache module, even though
the main fhttpd process is nonblocking.

  I don't know, what direction will be used by Apache for handling modules
if the server will become completely threaded, I assume that they will
either keep the same model, and will require modules to become
threads-safe or even aware of threads support library (pthreads, NSPR?),
or will provide some way to handle things the old way through some wrapper
(FastCGI?).

  fhttpd is unlikely to become threaded in its main module at least until
I will finish its optimization that I do within the nonblocking model,
however the modules API library most likely will become threads-safe in
the near future, so if PHP will become "really" thread-safe and will get
any kind of benefit from that, fhttpd will be able to run multithreaded
PHP while keeping itself non-multithreaded, or continue to use "normal"
mode of PHP with blocking i/o. I have no plans to port fhttpd to NT

#ifndef SERIOUS
(if I looked for as much trouble as Apache is having with Win32 port now,
I'd rather started "The GPL'ed Qt clone" development ;-)
#endif

, however it's possible to port PHP fhttpd module to NT for use in
remote module mode (connected with the main server by TCP). 

--
Alex