apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel May" <dan...@spryware.com>
Subject RE: apr_proc_trylock for linux
Date Tue, 16 May 2006 01:23:37 GMT
Sorry Bill, when you said 

"Since most unix boxes and applications are very happy to have multiple
instances of the same application in use at the same time, can you help
clarify what this sort of API accomplishes or is used for?" 

I thought you were asking me when I would use such a feature.  There are
plenty of good reasons to limit an app to a single instance, but I do
not think that is the point to argue here.  You suggested the
apr_app_proc_instance(), which could be used to accomplish the task.
The real issue is that named locks aren't working properly across all

I am happy to wait and test 2.0 to see if apr_proc_mutex or
apr_global_mutex work as expected.



-----Original Message-----
From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net] 
Sent: Monday, May 15, 2006 4:40 PM
To: Daniel May
Cc: dev@apr.apache.org
Subject: Re: apr_proc_trylock for linux

Daniel May wrote:
> We specifically use it for demon like processes under Windows and 
> Linux where we need to limit a single instance to run.

Of course I knew what you were doing, I'm pointing out that it's bad
practice in environments where it's completely sensible to run multiple
instances of a daemon configured differently.

Apache httpd uses the pidfile to designate a unique instance of the
daemon, and the user needs to configure it as such.

Please don't tell me 'but on windows'... because I'm running 2 - 12
seperate instances of httpd on seperate ports; mostly for testing - but
have plenty of clients who run multiple instances for completely sane
production purposes, such as fault isolation and so forth between
different web services.

What I was getting at is this both a portable problem for the apr
library to provide help for, and is it a -good- coding practice we
should endorse by providing the mechanics?

I can think of one use case in Apache, the ApacheMonitor taskbar app.
But due to that 'feature' multiple users in different login sessions
can't all have the ApacheMonitor taskbar app present.  In that case, the
real question which should be asked was "in this desktop, does
ApacheMonitor.exe already own an icon?", and not "on this system, is
ApacheMonitor.exe already running?".

Likewise with httpd (which uses the failure to grab listeners as it's
signal that it was already running) the question could be asked "is
httpd parent already running from /instance/x/conf/httpd.conf?" based on
-d /instance/x or on -f /instance/x/conf/httpd.conf.

So if you haven't guessed from this post, it really troubles me to
implement a 'feature' which promotes less portable, less flexible coding
Needless to point out by now, the mutexing api in API was not built to
do this, and so can't be legitimately be considered a bug.  The fact
that named locks aren't working portably *is* a bug which must be
resolved, overhauled in 2.0.


View raw message