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: Terry Lambert <email@hidden>
- Date: Tue, 24 Apr 2007 05:47:23 -0700
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.
-- Terry
_______________________________________________
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