httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: regarding mod_status and scoreboard API_EXPORTs
Date Fri, 15 Aug 1997 01:13:01 GMT
On Thu, 14 Aug 1997, Doug MacEachern wrote:

> Dean Gaudet <> wrote:
> > I'd like to remove the API_EXPORTs from the various scoreboard functions
> > which mod_status uses and dictate that mod_status cannot be a DLL.  My
> > reasoning is that these interfaces are quite private, and subject to
> > change.  
> This will break the Apache::Scoreboard module, but no worries, I was
> just playing with that, I don't think anyone actually uses it.
> However, mod_perl users are always asking "how can I create a shared
> memory segment and use it from mod_perl?".  Since the scoreboard stuff
> is already ported to so many platforms, it would be nice if there was
> a slot or another segment for modules to use the apache shared memory
> mechanism.  Would something like this be feasable?   

This is on the list in my head for 2.0.  Essentially I want to allow for
primitives like shared memory, and mutexes.  Not all models will support
all this functionality, but that's tough.  I want something that lets us
move forward with new architectural features.

Right now I'd say the only way for you to give them shared memory is to do
the work in init_module for mod_perl. 

> Sure it is, see INSTALL.win32 :-)  In fact, once 1.3b1 is here, I'll
> probably cut a binary distribution. If a change is made so this can't
> be accessed in a dll, that's fine, Apache->seqno won't work 
> #ifdef WIN32.  As we discussed, there should be a better way to get
> some kind of sequence number besides digging it out of the scoreboard.

Right.  I should post my idea for this... 

> > The scoreboard is very tightly related to the spawning and thread mgmt
> > model in use by a particular port.  In 2.0 we'll probably have a few more
> > models than we already have.  I know there's one model that I really want
> > to experiment with -- worker OS threads, and user-threads for apache code
> > -- essentially like NT threads and fibers with completion ports.  This is
> > widely believed to be the most scalable threading model (and it pre-dates
> > NT).  The other models include: 
> > 
> > - multi-process
> > - multi-process, multi-OS-thread
> > - single-process, multi-OS-thread
> > 
> > The beauty of Apache's design is that the work for any of these models is
> > limited to http_main almost entirely.  There are things we need to add to
> > the API to allow modules to take advantage of certain models (i.e. the
> > multithreaded models need mutexes to implement things like process-wide
> > mmap caches).
> Very beautiful!  The DCE plugin just needs to -DSTANDALONE_MAIN, and
> the rpc_server_listen() single-process, multi-thread model works like
> a charm.  Things could be better, but these things can/haveto wait for
> 2.0 I think.

I actually want to abstract the protocol layer (well it's already pretty
well abstracted, except a few pieces are done in http_main).

I want the process/thread/dispatch layer to be abstracted... and provide a
mechanism to register descriptors for a select() loop in child_main.  On a
successful select() for read it'll pass control back to the registered
callback ...  the default code would include a callback that handles
TCP/IP sockets to speak pure HTTP.  Your code would include a callback
that handles DCE gunk (you can do select() based DCE gunk right?).  This
way you wouldn't have to duplicate code from standalone_main or
child_main, and your code wouldn't need to know much at all about the
process model.

The callback will essentially be running in whatever our "smallest" 
execution unit (process, kernel-thread, user-thread) is in the model being

Hey can you send me your standalone_main so that I can make sure my
abstraction makes sense? 


View raw message