Re: Locking a shared memory object (crash safe )
Re: Locking a shared memory object (crash safe )
- Subject: Re: Locking a shared memory object (crash safe )
- From: Jonas Maebe <email@hidden>
- Date: Wed, 19 Mar 2008 14:56:25 +0100
On 19 Mar 2008, at 14:50, Nicholaz Beresford wrote:
Jonas Maebe wrote:
Note that if you unlink the semaphore right after creating it,
trying to sem_open() the same semaphore (i.e., passing the same
name to sem_open) will get you a new semaphore rather than the
previously opened/unlinked one (and this may or may not be a
problem).
As far as I understand it, other processes (started later) would
then create their own (independent) semaphore
Indeed.
which would defy the purpose of what I am trying to achieve
(allowing a cross process lock).
That approach is indeed only useful if you use it for communication
across different threads (so you can pass along the pointer to the
created semaphore) rather than communication across different
processes. In this case you can always create a launcher wrapper app
which creates/cleans up the semaphores (possibly already cleaning them
up if they existed in the first place, so you also work around force
quitting the launcher app).
Jonas
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden