Re: Anything wrong with x86_64 and SYSV shared memory allocation?
site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On 24 apr 2007, at 14:00, Terry Lambert wrote: -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On Apr 24, 2007, at 5:13 AM, Jonas Maebe 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. This email sent to site_archiver@lists.apple.com
participants (1)
-
Terry Lambert