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
