From owner-freebsd-current Fri Dec 13 9: 3: 8 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC21D37B401 for ; Fri, 13 Dec 2002 09:03:05 -0800 (PST) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4614143EC5 for ; Fri, 13 Dec 2002 09:03:05 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from rev208-187-98-122.wolsi.com ([208.187.98.122] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18MtDH-0000WZ-00; Fri, 13 Dec 2002 09:02:59 -0800 Message-ID: <3DFA1251.C4755C5B@mindspring.com> Date: Fri, 13 Dec 2002 09:01:05 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Joe Kelsey Cc: freebsd-current@freebsd.org Subject: Re: Posix Semaphores in -CURRENT References: <3DF8F08E.8050809@mail.flyingcroc.net> <3DFA0771.BDFC87A8@mindspring.com> <3DFA0DAC.2070801@mail.flyingcroc.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a46dd43eae41b9a6107ece01387bd8a380350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 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. [ ... ] > Did I say anything about threads? Why would named posix semaphores > depend on threads? My mistake. I suggest you use System V semaphores, instead, if you do not need threads interoperability. Your code will be more portable that way, too. > > 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? The semaphores are technically hierachical object references; you should think of them as file references, as an implementation detail. It's a namespace issue, more than anything else(*). > 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. I would need an exact version of the source files you are referencing, at this point, to be able to say anything more meaningful, sorry. > 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? Actually, I believe they are real file references. The issue with making them imaginary, as you seem to imply (e.g. the "special directory entry") is that the path names are actually redesvous, and you don't want them being duplicated, and you want them to be look-uppable. IMO, they will probably be 0 length regular files, unless they have to persist across reboots with stte, in which case, they will contain state information. Get me the exact file you are concerned about, and I will stare at it with you. I think, though, that if there is a problem, it's just that you are catching things in mid-implementation (POSIX semaphores were supported in the other scope, but not system, until very recently; there's even magic POSIX manifests that tell you not to use them). -- Terry (*) True for the implementations whose source I have examined; probably not true for every implementation, and possibly not true for the final FreeBSD implementation. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message