Date: Fri, 13 Dec 2002 08:41:16 -0800 From: Joe Kelsey <joek@mail.flyingcroc.net> To: freebsd-current@freebsd.org Subject: Re: Posix Semaphores in -CURRENT Message-ID: <3DFA0DAC.2070801@mail.flyingcroc.net> References: <3DF8F08E.8050809@mail.flyingcroc.net> <3DFA0771.BDFC87A8@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > 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). I am not interested in threading. Named POSIX semaphores are inter-*process* synchronization more than they are inter-*thread* synchronization. I do not care about unnamed semaphores. > 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. Did I say anything about threads? Why would named posix semaphores depend on threads? >>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. So, is there some mechanism I am missing? Is there a layer between the application calling sem_open and the kernel receiving the parameters that strips it down to the last component? If there is a higher level involved here, why is the low-level ksem_create function worrying about embedded '/' characters? >> 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. Yes, I realize this, but it seems that from my cursory inspection of uipc_sem.c that the check for embedded '/' characters is unnecessary and much too restrictive according to the posix standard. The standard only talks about whether or not the semaphore name begins with '/' and has nothing to say about embedded slashes except that the name must conform to filename requirements. It seems to me that either you take the TRU64 approach and place a marker in the file system (special directory entry?) or you allow all strings, only looking at the first character and not caring about anything else, except for whatever maximum pathname requirements you choose to impose. Maybe I am missing something in the system call semantics? /Joe 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?3DFA0DAC.2070801>