> True, we have to implement it. But we don't have to spend a lot of time
> getting it super fast, or particularily elegant. I'd concetrate on
> those parts of the POSIX.1b spec that are likely to be actually used by
> real applications.....
But I think that the named semaphores can be implemented on top of
the unnamed semaphores. The kernel should keep a list of the names
(the pseudo-filesystem) and return handle for a semaphore from the
common pool.
When I go back to my initial proposal:
sem_init() returns simply the next free semaphore in the buffer
while
sem_open() looks whether there is such a semaphore. If not and O_CREAT
is given is returns the next free semaphore, i.e., it implicitly
calls sem_init()
The functions which use semaphores behave the same.
(Please note that I don't talk anymore about a second pool for local
semaphores. Xavier pointed out that this is really stupid since it
would be slower than using a user-level only implementation.)
One point still not clear is whether it's worth to create a
pseudo filesystem for the named semaphores. I would vote for it
and the standard author encourage this use. It would allow easy
maintenance of the semaphore namespace. Keeping all names in a
plane namespace (i.e., treating / as a normal character) would
be simpler but once the semaphores are implemented I would think
hundreds of semaphores used at the same time is easily possible.
How do you like a directory with hundreds of entries? The POSIX
people gave us this mean of structurization so me should use it.
-- Uli
--------------. drepper@cygnus.com ,-. Rubensstrasse 5
Ulrich Drepper \ ,--------------------' \ 76149 Karlsruhe/Germany
Cygnus Support `--' drepper@gnu.ai.mit.edu `------------------------