Re: Anything wrong with x86_64 and SYSV shared memory allocation?
Re: Anything wrong with x86_64 and SYSV shared memory allocation?
- Subject: Re: Anything wrong with x86_64 and SYSV shared memory allocation?
- From: Jonas Maebe <email@hidden>
- Date: Tue, 24 Apr 2007 15:02:48 +0200
On 24 apr 2007, at 14:47, Terry Lambert wrote:
On Apr 24, 2007, at 5:13 AM, Jonas Maebe wrote:
On 24 apr 2007, at 14:00, Terry Lambert wrote:
Oh, and Chris also suggests using System V semaphores instead of
POSIX semaphores in Postgres, to avoid the fd pressure
But then you get the problem of leaking semaphores in case a
program crashes or is abnormally terminated, no? (requiring manual
cleanup with ipcs)
Or you just use the same key file with ftok(), which will get you
the same key each time, and always attempt to delete them at
program startup, ignoring the error if they weren't there to delete
because you didn't crash/weren't aborted.
Of course, POSIX semaphores can be forced to be resource tracked
using sem_unlink() after the last sem_open(), but once they are
unlinked, subsequent sem_open()'s fail until everyone has drained
out their references through either _exit() or sem_close(), so they
are more or less in the same boat.
Whether the cleanup happens because of a sem_unlink() at startup by
path, or an ftok() by path to get a key, and a semctl() call, you
are explicitly cleaning things up, either way, with either interface.
I'm mainly interested in this from a compiler run time library point
of view, which offers a generic synchronisation object. Currently I'm
indeed using sem_open/sem_unlink. The name is constructed on the fly
based on a.o. the process id and thread id, so it should never
conflict with another process/thread.
In this scenario, cleaning up in case of collisions is not really an
option, since you may run out of available semaphores before you get
a conflict to clean up.
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