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.

Bill




Mime
View raw message