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);
and
apr_user_proc_running(...,const char* name);
At the moment i used mutexes with the uid encoded into the name...
Hans-Peter
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
