apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: Problem with apr_proc_mutex
Date Fri, 28 Mar 2003 04:49:32 GMT
At 07:48 PM 3/27/2003, Spinka, Kristofer wrote:
>My thoughts,
>1. The naming is absolutely necessary if other, non-fork()'d, processes
>wish to find and use these resources; easily.

Agreed, valuable on fork()less platforms and especially for all applications
that won't fork (co-processes etc).

>2. Using some sort of namespace identifier, such as your proposed "ApR"
>is definitely attractive for diagnostic purposes.

And namespace protection, as well, so that we don't trip on other
mutex-using applications.

>3. The whole 14 character b/s with POSIX is quite outmode, and many
>platforms do *not* enforce this limit.  Perhaps APR should have a strict
>POSIX mode, and a "modern" POSIX mode that can be detected with a
>configure-time test.

+++1!!!  Definitely preferable to determine this at build time.  Fallbacks
at runtime are also valuable, but for applications to have some sort of
APR_MUTEX_NAME_MAX_LEN value is quite helpful.

>4. Using a hash will destroy the human readability/associability factor
>(during diagnostic time).

:-(  I absolutely agree... although diagnostic output (logs et al) does help.
Remember we have an apr_proc_mutex_name() to recover the name used.

>5. If APR applications allocate *many* system-globally scoped resources,
>it might be better to stuff them into an APR managed shared memory block
>(that has its own symbol name lookup table) and only consumes one global
>identifier.  Once a foreign process is attached to that globally-named
>memory block, it can use some new APR API to search a dictionary
>embedded at the head of that block.

Absolutely.  This thought mirrors my ideas for HTTPD, in terms of providing
some mechanism for passing a large group of log file handles, mutexes and
other shared resources.  I was thinking about a pipe and list, but any which
way conserving resources this way would be useful.  Keep in mind, though,
that atomics (while useful) aren't always the answer.


View raw message