So, does that mean that if process 1 opens a semaphore, process 2 also grabs it, then process 1 unlinks it, and then "reconnects" to it, that process 1 and process 2 do not have and cannot have the same semaphore anymore, even though they are using the same IPC_KEY?
(Or am I way confused/off base here)? On Thu, 09 Dec 2004 17:44:42 +0100, Corinna Vinschen wrote: >[Catching up on some older mails] >> ----- Forwarded message from "Gerrit P. Haase" ----- >> From: "Gerrit P. Haase" >> To: cygwin ML >> Subject: sem_* functions in cygwin >> Date: Sun, 21 Nov 2004 22:48:20 +0100 >> >> Hi, >> >> nearly all sem_* functions are available, but sem_unlock is missing, >> was there a problem implementing sem_unlock() or was it just missed >> by accident? >> >> >> Gerrit >> ----- End forwarded message ----- >I guess you're asking about sem_unlink(). It's not implemented so far >since named POSIX semaphores are implemented using named Windows semaphores. >The SUSv3 description contains a pretty unfortunate implementation detail: > Calls to sem_open() to recreate or reconnect to the semaphore refer > to a new semaphore after sem_unlink() is called. >There's no way I know of, which allows to implement this using named >Windows semaphores. At least not without adding a lot of annoying >bookkeeping overhead, possibly involving cygserver. >Corinna >-- >Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple >Problem reports: http://cygwin.com/problems.html >Documentation: http://cygwin.com/docs.html >FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
