> - Provide a generic inter-process data-sharing framework. Currently
> mod_ssl, mod_auth_digest, mod_ldap, and the scoreboard all use
> more-or-less independent implementations of shared memory data stores.
> As someone who maintains a module with yet another such data store,
> I think a standard interface for such things (beyond apr_rmm) might be
> useful. Perhaps something key/value based; maybe aligned with memcached
> somehow? See my final musings below.
>
> - Provide a generic scoreboard interface for use by modules. The
> current scoreboard is effectively sized at initial startup to
> max MPM processes * max MPM threads. That wastes space, but also
> provides no way for modules to register their own private threads.
> As someone who maintains a module with such threads, I'd love to
> see them in mod_status. I'd also like to see the non-worker threads
> from an MPM like worker in there too (i.e., listener, start, main);
> I have a collection of incomplete patches to do this hanging around.
>
> Admittedly, this may be a hard problem: how do you size the scoreboard's
> block of shared memory if modules can be added at restarts, and might
> suddenly require extra scoreboard space for their threads? I have no good
> solution. (Should the scoreboard use the above-mentioned generic
> data-sharing framework, or not? Perhaps shared memory isn't even the
> right tool?)
You need different kinds of "shared" memory:
- stuff with one writer and several readers.
- stuff with several writes and several readers.
httpd-proxy-scoreboard in fact only solved the first one and only
provide memory organised in slotmem (records).
The idea to have a provider of "shared" memory and use it for the
scoreboard is of course a need for the next version and there should be
a way to access to httpd scoreboard from in external process (for
example a java process for JMX access). Once the configuration is
readable and dynamic it could be forwarded to the next node of an
"httpd" running in a cluster.
If you have something something like the workers of mod_proxy it must
possible to add a new worker (a new node of cluster front-end by httpd)
without the need of restarting httpd. A not easy problem is to remove a
worker.
>
> If we're generally moving to an increasingly asynchronous, threaded
> design then I think such a scoreboard might also serve as a valuable
> sanity check during development ("What the heck is that thread doing?")
One need thing is to be able from a module to ask for a "timeout": some
thing like a dummy request that happens after a timeout if no requests
are coming. (To query a back-end server for example).
>
> An API which allowed threads to register their possible states might
> be valuable; this would allow modules/providers/MPMs to define what
> states were meaningful to them, rather than trying to define them
> all in scoreboard.h.
>
> I confess I haven't followed the progress of the httpd-proxy-scoreboard
> branch; maybe there's some work in there that would apply to these issues.
>
>
It is a bit dormant for the moment.
Cheers
Jean-Frederic
