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: Fix for SSLMutex bogusness
Date Sun, 23 Feb 2003 20:27:02 GMT
At 01:08 PM 2/23/2003, Dirk-Willem van Gulik wrote:

>> That's what I assumed Dirk meant... A "standard" lock format
>> such as "mechanism:/file/path". So AcceptMutex, for example,
>> would use that and we'd avoid LockFile.
>
>Aye - so that other things also requiring a Mutex (I am struggling with
>some PAM/radius stuff right now) can be similarly configured.
>
>It may be as simple as having an apr mutex which takes such a 'URI' as an
>(optional) argument. In that case you'd still expect the user app to have
>SSLMutex, PAMMutex and so on.

Our create mutex takes a numeric choice of locking mechanisms and
a filename string.  I don't see necessarily a benefit to changing that API.

What I would like to see in Apache server/util.c is a simple text-based
API for creating that selection criteria, with some text feedback.  We
have neglected all i18n of feedback messages in APR, and I don't want
to pollute APR with more such feedback until we really get a handle on
how to address that.

Perhaps a function;

char *ap_choose_mutex(char **result_str, apr_lockmech_e  *result_method,
                     const char *request, apr_pool_t *p);

could return result_str and result_method and a NULL rv on a good request, 
and a string of the valid codes on failure (pass request of NULL to simply
recover the list for info messages.)  It would be up to the caller to further
decorate with "Invalid mutex type chosen, valid XXXMutex options include;"
text because that would all vary by caller.

I don't know that polluting the filename argument with decoration is a
good thing, that is a very apache-centric construct, and other applications
might choose another way of choosing locking mechansims.

I'll implement this afternoon with some +1's.

Bill



Mime
View raw message