apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans-Peter Weidinger <hans-pe...@hp-weidinger.at>
Subject Re: apr_proc_trylock for linux
Date Tue, 16 May 2006 14:20:30 GMT
Hi Bill,

I think your last suggestion is the most suitable for me.
I would have needed the mutex to have multiple processes (communicating 
via SHM) are aware that a
server (reading SHM) is available. So they can put data into the 
shared-mem and terminate.

The ressource would be the shared-mem then.

But i think its more flexible to have a mechanism that uses e.g. names 
for abstract ressources.
The api could be provide this on a "per login" and "global" manner.
Something like:
apr_global_proc_running(...,const char* name);
apr_user_proc_running(...,const char* name);

At the moment i used mutexes with the uid encoded into the name...


William A. Rowe, Jr. schrieb:
> James Mansion wrote:
>>> 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 think this is a rather common requirement for desktop apps.  In UNIX,
>> it would commonly be used on a per-login basis (sort of thing you'd get
>> a DBUS session bus instance for) but remember that its also effectively
>> used by init, and for server stuff its handy if you have a daemon that
>> is wanting to receive all UDP traffic broadcast to a particular address.
> *Bingo*.  We don't simply tie this out to 'this process (binary) is 
> running',
> but it probably needs a modifier, e.g. 'this process in this login is 
> running',
> or 'this process using resource X is running'.
> So let's talk about some API for apr_app_proc_running( [???] ) that we 
> could
> consider for inclusion 1.3.0?  I'm fairly certain this is something we 
> can
> do portably.  Offers of help on other OS's if I tackle WinNT?
> Bill

View raw message