Date: Wed, 18 Sep 2002 19:57:24 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: Alfred Perlstein <alfred@FreeBSD.org>, hackers@FreeBSD.org, deischen@FreeBSD.org, Garrett Wollman <wollman@lcs.mit.edu> Subject: Re: sem_init help? Message-ID: <3D893D14.E06E3BA8@mindspring.com> References: <Pine.GSO.4.10.10209182206210.3071-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: > Yes, but it doesn't change what the spec says above. It's > implying that any process can perform sem_destroy() on it and > the spec also says for sem_init() that "This semaphore shall > remain usable until the semaphore is destroyed.". The key point is "that can access". It restricts the scope to processes that can access the shared resource. > So the sem_init()'ing process can exit and leave the destroying > to one of the other processes that have access to it. Here's my argument against that, from the sem_destroy() man page: It is safe to destroy an initialised semaphore upon which no threads are currently blocked. The effect of destroying a semaphore upon which other threads are currently blocked is undefined. By itself, "undefined" here isn't very damning. But if you look at the return codes that a caller should expect to have to handle EBUSY; the text is thus: The sem_destroy() function will fail if: [EINVAL] The sem argument is not a valid semaphore. [ENOSYS] The function sem_destroy() is not supported by this implementation. The sem_destroy() function may fail if: [EBUSY] There are currently processes blocked on the semaphore. ...the implication here is clear: the sem_destroy() function may or may not know enough to be able to return an EBUSY error, based on how it was implemented. What this implies is that the implementation can optionally do what you say: > The semaphore remains active until it is destroyed. ...i.e. doing this is permissable, but... it would be a hairy problem to track shared memory and mmap'ed region deletions to track deletion of shared regions containing blocked semaphores. 8-(. > If you don't want to track its page, can you hook it into ipcrm(1)? Ugh, please, no! 8-) 8-). If people want persistent semaphore objects using the POSIX semaphores interface, they are supposed to used named instead of unnamed semaphores. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D893D14.E06E3BA8>