httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug MacEachern <>
Subject Re: regarding mod_status and scoreboard API_EXPORTs
Date Fri, 15 Aug 1997 00:05:12 GMT
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?   

> Doug I remember that I broke something in mod_perl when I created the
> union {} in the scoreboard... but I forget exactly what broke.  

That was Apache->seqno, which pulls out
I've fixed it based MODULE_MAGIC_NUMBER

> It's not
> possible to DLLify mod_perl though, right?  So doing this wouldn't break
> it?

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.

> 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.


View raw message