httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug MacEachern <do...@opengroup.org>
Subject Re: regarding mod_status and scoreboard API_EXPORTs
Date Fri, 15 Aug 1997 14:41:43 GMT
Dean Gaudet <dgaudet@arctic.org> wrote:

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

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

Yeah, I just wanted to avoid the #ifdef fiasco :-)
 
> > 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... 

I see it, looks great, +1 here.
 
[...]
> 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.

No select(), no socket(), no bind(), no listen(), no accept(), it's
all done under the covers (in the DCE runtime) by rpc_server_listen().
It's considered a feature of DCE, that RPC programmers don't need to
deal with network transport stuff, instead we get all kinds of other
gunk to deal with.
 
> The callback will essentially be running in whatever our "smallest" 
> execution unit (process, kernel-thread, user-thread) is in the model being
> used. 
> 
> Hey can you send me your standalone_main so that I can make sure my
> abstraction makes sense? 

Well, unlike mod_perl, I was paid for the DCE stuff, so I'll have to
ask first :-/  I can say, there isn't much duplicate code at all, just
calling a handful of core routines and using a few apache globals,
e.g. server_conf, pconf, ptrans, etc.

-Doug

Mime
View raw message