Date: Fri, 13 Dec 2002 09:01:05 -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: <3DFA1251.C4755C5B@mindspring.com> References: <3DF8F08E.8050809@mail.flyingcroc.net> <3DFA0771.BDFC87A8@mindspring.com> <3DFA0DAC.2070801@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 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DFA1251.C4755C5B>