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 platforms. I am happy to wait and test 2.0 to see if apr_proc_mutex or apr_global_mutex work as expected. /Daniel -----Original Message----- From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] Sent: Monday, May 15, 2006 4:40 PM To: Daniel May Cc: [email protected] 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 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. Bill
