httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Massimo Manghi <>
Subject threads caveats working with 'worker' mpm
Date Mon, 01 Aug 2011 23:34:08 GMT

I'm in the process of figuring out if mod_rivet could fit
into an Apache http server using 'worker' as mpm.
Rivet embeds Tcl in Apache and enables server side
scripting using the Tcl language in pretty the same style
you can do using PHP, for instance.

I don't even know if this is possible as the big PHP itself
for long time used to work only with a prefork server
(and maybe still does...), but having threads could be a
plus on heavily loaded servers and on certain architectures.
So here I am...

I tried an empiric approach, recompiling both Apache and
Rivet with 'worker' as mpm and with debugging symbols, just
to see what's going one in a threaded server.
I assumed that basically threads would take the role that
used to be a child's role with prefork. Instead it seems
that threads are managed following a different logic:
apparently threads are created when a request comes and
their number seems not to be restricted by the
parameter ThreadsPerChild (I set it as 2)

The module seems to work (it logs data) but eventually it's
unable to send data down the connection, most likely because
the Tcl interpreter gets spoiled somehow (shouldn't just
one thread be running if I have a single request being served?)

I'm puzzled. Googling the subject didn't add more to what
I already knew, so my questions are:

  - is the a general paper about the worker mpm as seen
from the developer perspective?
  - Apart the usual caveats of accessing global/shared data
after a Mutex lock has been gained, what a module is supposed
to do in order to handle threads properly?
Nick once said modules must be mpm agnostic as much
as possible. Maybe it must be read as "module must
be mpm agnostic if they can?"
  - How a child process can setup a thread environment and its
private data?

  I apologize for the lengthy message. Thank you if you have
read it up to the bottom line

  -- Massimo

View raw message