Garrett Wollman wrote:
<<On Fri, 13 Dec 2002 08:41:16 -0800, Joe Kelsey <[EMAIL PROTECTED]> said:


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?

I find this rather puzzling.  Speaking as a standards person, I can
state with some certainty that *the name of a POSIX semaphore is
intended to have path name semantics*.  It is not required to be an
actual path name, but there is a clear expectation that a quality
implementation will do so.  The POSIX developers saw these IPC objects
as being analogous to shared memory objects or fifos, and did not see
a compelling reason to invent an entirely new namespace for them.
What are you puzzled about? I am asking why uipc_sem.c checks for embedded slashes. I agree with you that it should allow arbitrary pathname strings as semaphores and it appears to me that it does not, in fact, allow arbitrary pathname strings as named semaphores.

I am asking where my misunderstanding of uipc_sem.c is, or if I do understand it correctly, why does it place this restriction on named semaphores.

Stevens actually suggests an implementation of named semaphores in
which the semaphore is represented by a file which contains the name
(``key'') of an SVID semaphore.
That would be a truly horrid implementation of named posix semaphores. I was hoping to get away from all SVID-related anachronisms here.

/Joe




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to