site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Apr 2, 2009, at 2:03 AM, Terry Lambert wrote: Of course. Thanks. The engineering perspective was what I was interested in. -- Steve Checkoway "Anyone who says that the solution is to educate the users hasn't ever met an actual user." -- Bruce Schneier _______________________________________________ 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... This email sent to site_archiver@lists.apple.com On Apr 1, 2009, at 9:31 PM, Steve Checkoway <s@pahtak.org> wrote: Is there a technical reason that Darwin doesn't support POSIX unnamed semaphores or it's just not a priority since they're not necessary? I can give you technical information about why I haven't personally done it, but realize I am not speaking officially in any capacity by doing so. With that in mind, I'll try to answer your questions from an engineering perspective, rather than putting it as the more pragmatic "if Apple implemented POSIX unnamed semaphores, how many X Serves would you buy?"... They aren't required for UNIX conformance because they are not mandatory interfaces per Appendix 9 of the Single UNIX Specification, and there are lots of alternatives, most of them with better overall semantics, which this tread has amply demonstrated. Most portable and historical software uses System V semaphores, since POSIX semaphores are relatively new, so there's little software portability incentive. The software which does like to use them is typically based on GNU autoconf/automake which typically uses linkage tests to find interfaces and blows it by doing that and ignoring <unistd.h> contents, since historical conformance with older versions of the specification permitted stub functions which errored out, and the linkage tests only check linkability rather than functionality. So basically the software that wants them usually fails to conform to the standards which would have allowed them to be used safely and reliably in the first place. Then there is the little problem of binary backward compatibility for POSIX named semaphores, if the error or success returns don't happen to match the standard once testing of a full implementation became possible. As a Mac OS X implementation detail, sem_t is the required data type for both POSIX named semaphores and POSIX unnamed semaphores according to the standard. The sem_t definition has historically been a 32 bit value containing an fd cast to a pointer, which is problematic for maintaining binary and source backward compatibility (hint: think symbol decoration) for named semaphores while at the same time permitting typical usage of unnamed semaphores. Specifically, typical usage of unnamed semaphores is to use them as an IPC synchronization mechanism between otherwise unrelated programs by allocating a shared memory region shared between them of sizeof(sem_t)*number_of_semaphores_desired, and the casting the base address of that memory region to a (sem_t *) and indexing off that to get a semaphore index in the range 0.. (number_of_semaphores_desired - 1). The implementation problems should now be obvious. They are not insurmountable; I sometimes pose how to resolve the conflicting goals involved as an interview question. 8-). But there isn't really a very obvious fix I'd call elegant, either. After reading your response and the notes for fp_getfsem, I believe I see the issues. Thanks for taking the time to explain. Maybe someone will surprise me someday, or maybe an outside developer will attach elegant code capable of balancing the conflicting goals to a bug report the next time they request the feature, or maybe someone will contract to buy a bunch of X Serves. I'm afraid I neither need the feature nor have the money to buy a bunch of Xserves. I was just curious about its absence. smime.p7s