httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hyde <>
Subject RE: thread safe modules
Date Fri, 12 Dec 1997 21:32:37 GMT
My reptilian brain is, as said shocked, since it having this powerful
frightening reminding.  As a commercial vendor
with a few plugin APIs I have, from time to time, shipped changes that
didn't do what the last version did, but instead did what the previous
version was  "documented" to do.  Each time I did that it was followed
by long painful meetings and site visits with customers that didn't
even have the ability to revise their modules anymore.

Adding the requirement that the module is thread safe is triggering
this reaction.

Apparently your comfortable that since it's limited to Window's it won't
that much of a back lash, and that meanwhile the next version won't
abandon the current
process model so it won't happen then either.  My rational brain is
seeming to fall for that.

The part of my rational brain in contact with my reptilian brain thinks
would be possible to default, or let the module declare, that it must
the access to it serialized - per call, per request.

The evil marketing part of my brain will now speak up.
Doing so would lower the barrier to migrating modules.
The pool of products built on top of Apache provide a great asset in
to achieve a beachhead on Windows.  Why make it hard for them to get
Sorry about that, I'll tell him to shut up.

    - ben h.

On Friday, December 12, 1997 2:39 PM, Dean Gaudet
[] wrote:
> You seem to be saying that the Apache group has managed to promise
> code written for a single-threaded server will magically work on a
> multithreaded server.  That would be quite the feat.  It works
> if you store all your data in per request structures, and have no
> data.  What more could we promise? 
> There's a bit of history here that unfortunatley has never been
> documented, or maybe it is somewhere.  Apache was originally designed
> support multithreading, and there was even a 1.0 version of the server
> which was multithreaded.  These itty gritty API details were mostly
> correct even at that time; and modules were supposed to be thread
> However a lot of time has passed since then, and this stuff has never
> really been documented that well.  The API which was in the
> server has been lost (it has copyright issues), so folks have been
> developing modules to an incomplete API.
> Given that we haven't supplied the basic mutex primitives until 1.3
> nothing could even hope to run in a threaded apache.  I know there are
> modules with global state -- for example, the sql auth modules which
> a handle to the database open.  They will have to be ported to win32. 
> Modules which dink with absolute pathnames have to be ported to win32.

> There's probably a few other things which we don't express in our API
> which unix modules use and will have to be ported to win32.  WIN32 is
> unix, and we haven't been providing a complete portability layer...
> so is a huge undertaking. 
> So Unix users assuming that their stuff runs on win32 can be
> But that's not going to break the unix modules on unix. 
> They will break when we have a multithreaded unix.  But we won't be
> ditching the old process model, we'll still have it.  So folks with
> modules can bring them forward, they'll just be using the old process
> model.  If they want to use the new model they'll have to put effort
> making their stuff multithread safe.
> Dean
> On Fri, 12 Dec 1997, Ben Hyde wrote:
> > I heartly agree putting a mutex into palloc() is a bad
> > idea.
> > 
> > But I'm shocked.  Yes it's a bummer but by default the old
> > contract was that a module was called in a thread safe way.
> > I'd never be able to tell my customers I was changing an
> > API in this manner.  Reminds me of all those casual changes
> > Sun made moving to Solarius (and it's currently regularly
> > making to Java).
> > 
> > This is made worse that the change only effects the new
> > market, i.e. WIN32.  First it increases the barriers to
> > entry for applications layered on top of Apache, i.e.  it's
> > not just of matter a recompile.  Second it lays a trap for
> > the Unix users: they need not convert and then later you'll
> > be telling them "Oh, yeah we changed the rules quite some
> > time ago."
> > 
> > Yes the core modules are wonderfully stateless, but what's
> > that prove about customer modules?  Surely it doesn't prove
> > that they should be stateless, or even that they are
> > typically stateless.  What percentage modified mod_example
> > to get started?
> > 
> > A possible compromise is an pseudo module that encapsulates
> > a classic module serializing it's callbacks.
> > 
> >  - ben
> > 

View raw message