Re: light weight user level semaphores

[Alon Ziv]

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" <[e-mail]>
To: "Alon Ziv" <[e-mail]>
Cc: <[e-mail]>; "Alan Cox" <[e-mail]>
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.
>
>
>