httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Re: project plan
Date Fri, 12 Jul 1996 16:58:52 GMT
  I can make the
  PHP part of mod_php thread-safe, but we have no control over libmsql.a
  and libpq.a.

FWIW, my current threaded prototype is built around a non-preemptive
threading package.  This means that once a thread is scheduled, it
keeps control until it takes some explicit action to give it up
(calling yield, exiting, trying to lock a mutex, or calling one of the
thread-specific I/O operations which allows other threads to proceed
while the caller is blocked).

So, code which just calls some msql-library routine will not find some
other thread trying to enter the same library routine within the same
address space behind its back --- not unless it has made specific
arrangements to allow other threads to proceed while it is waiting.
On the other hand, as the msql-invoking thread is waiting for the
msql server, all the *other* threads in that process are, in effect,
waiting for it as well, since they can't resume until it gives up the
processor.

In short, it will work.  However, depending on how frequent the
msql-induced delays are, it may not work very well.  As to how
to improve it...

  Hopefully RST's thread
  code can be told to only allow one thread at a time into these libraries.

Well, what you *could* do is hack msql to use thread-blocking I/O
(FWIW, ve haf vays to tweak a FILE* so that blocking I/O on it allows
other threads to proceed; this is used for CGI, etc.), and then guard
actual use of msql with a mutex.  The problem then becomes making sure
that all modules which use msql are using the *same* mutex as a guard.

("Mutex" == "mutual exclusion" --- basically, it's an in-core lock).

rst

Mime
View raw message