Date: Fri, 13 Dec 2002 08:14:41 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Joe Kelsey <joek@mail.flyingcroc.net> Cc: freebsd-current@freebsd.org Subject: Re: Posix Semaphores in -CURRENT Message-ID: <3DFA0771.BDFC87A8@mindspring.com> References: <3DF8F08E.8050809@mail.flyingcroc.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Joe Kelsey wrote: > I have been looking at the implementation of POSIX semaphores in > -CURRENT. I noticed that there are several missing pieces, specifically > the man pages and the removal of uthread_sem.c from libc_r. > > I suppose the man pages are not critical, but it seems silly to keep > uthread_sem.c in libc_r if there is a completely new kernel-based > implementation of the sem_* routines in -CURRENT. First, realize that there is no such kernel implementation, in the non-KSE case, and that the default in 5.0 is going to be non-KSE (which will wait until at least 5.1). Second, realize that even if there were a shiny, happy kernel implementation, it would be a bad idea to use it directly from a threaded program. This is because, even in the KSE world, the thread scheduler is a hybrid, and it's possible to have a multiplicity of threads in user space backed by a single kernel context. When this happens, crossing the user/kernel boundary does nothing for you... except to make your program run slower. > There are some other things about uipc_sem.c that seem unnecessarily > restrictive. For one thing, it *requires* named semaphores to begin > with a '/' but not contain embedded '/'. This seems like a severe > portabliity issue as TRU64 (at least) allows arbitrary pathnames as > sempahores, probably storing some sort of marker in the directories (I > get this only from examining the TRU64 online manual pages at > http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/HTML/APS33DTE_html/DOCU_010.HTM I guess the question to ask at this point is whether it's talking about disallowing embedding a '/' in a component, or disallowing it as a component seperator. I think you will find that it's the former. > There seems to be some broad interpretation of the POSIX semantice in > TRU64 to allow for negative semaphore values, one of their questionable > choices, although their example code is instructive). Since the > semaphore names are merely stored in kernel structures, what difference > does it make if they contain embedded '/' characters or not? And why > not allow names without leading '/'? I don't think that there is any > wording in POSIX preventing this. In general, an application should not assume interpretation of standards. If a standard is written such that it can be interpreted in more than one way, then the application writer should assume that some OS vendor has interpreted it in every possible way, and should not depend on behaviour that requires a single interpretation to be implemented by everyone. Sucks, I know, but the only way around it is to write your POSIX congressman. In general, I think these types of ambiguities arise *intentionally*: the standard is written so that existing implementations already comply with it, so that vendors don't have to change things, and can still claim compliance. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DFA0771.BDFC87A8>