site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On 24 apr 2007, at 14:47, Terry Lambert wrote: On 24 apr 2007, at 14:00, Terry Lambert wrote: Jonas _______________________________________________ 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. 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. This email sent to site_archiver@lists.apple.com