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: apr_proc_trylock for linux
Date Mon, 15 May 2006 21:39:54 GMT
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 practices.
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