httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: thread safe modules
Date Fri, 12 Dec 1997 19:35:37 GMT
You seem to be saying that the Apache group has managed to promise that
code written for a single-threaded server will magically work on a
multithreaded server.  That would be quite the feat.  It works perfectly
if you store all your data in per request structures, and have no global
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 to
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 safe. 

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 multithreaded
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 keep
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 not
unix, and we haven't been providing a complete portability layer... doing
so is a huge undertaking. 

So Unix users assuming that their stuff runs on win32 can be disappointed. 
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 legacy
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 into
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
> 


Mime
View raw message