Oh, I don't argue about that. (Well, almost--- see below...)
It's just that we need _some_ method for getting over the silly POSIX
FD-handling restrictions... And the negative-FDs may be the solution.
(Note I said we 'can' declare other semantics; not 'should'. So these
FDs can still be normal ones, just at the other end of the numbering
range...)
My misgivings are:
* There's no way to integrate other signalling mechanisms; e.g., we may
wish for a 'wake-all-waiters' signaller, or for a 'timed-wait' that
arrives via an FD and not as a signal
* a pipe is a more-or-less good semaphore; it may be too heavyweight,
as it's forced to pass useless [in this case] info, and we can't
control its wakeup order [although POSIX doesn't seem to require this]
[ Actually, I once had an idea of binding signals into an FD, so they can be
'read' out of it... with that, an alarm() is a 'timed-wait' waitable by
poll() :-) ]
-az
----- Original Message -----
From: "Alexander Viro" <[EMAIL PROTECTED]>
To: "Alon Ziv" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "Alan Cox" <[EMAIL PROTECTED]>
Sent: Sunday, April 22, 2001 16:31
Subject: Re: light weight user level semaphores
>
>
> On Sun, 22 Apr 2001, Alon Ziv wrote:
>
> > Well, that's the reason for my small-negative-integer semaphore-FD
idea...
> > (It won't support select() easily, but poll() is prob'ly good enough)
> > Still, there is the problem of read()/write()/etc. semantics; sure, we
can
> > declare that 'negative FDs' have their own semantics which just happen
to
> > include poll(), but it sure looks like a kludge...
>
> You _still_ don't get it. The question is not "how to add magic kernel
> objects that would look like descriptors and support a binch of
> ioctls, allowing to do semaphores", it's "do we need semaphores
> to be kernel-level objects". Implementation with pipes allows to avoid
> the magic crap - they are real, normal pipes - nothing special from
> the kernel POV. read(), write(), etc. are nothing but reading and writing
> for pipes.
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/