Re: AMIGA will use Linux, but Linux has several "multimedia-deficiencies"

Malcolm Beattie (mbeattie@sable.ox.ac.uk)
Thu, 15 Jul 1999 12:08:15 +0100 (BST)


Gerard Roudier writes:
>
>
> On Wed, 14 Jul 1999, Malcolm Beattie wrote:
>
> > Gerard Roudier writes:
> > > You can select on message queues on AIX, IIRC, but this is not portable.
> > > MVS accepts additionnal parameters for the select() that allows to also
> > > wait for events on other types of resources (in the case you really want
> > > to use select under this O/S).
[...]
> > What's wrong with the usual way of forking/starting a thread which
> > blocks itself and writes a byte down a pipe when it's done? That's a
> > standard generic way of including any blocking behaviour at all into
> > a select/poll based event loop. Roughly,
[...]
> This may work for you this way, but never will do so for me. :-) Adding
> threads, pipes, useless synchronisations or any kind of other plumbing to
> band-aid the O/S from user space is the way I am not going to follow when
> I can do different.

Plumbing tends to be a rather useful way of connecting things up and
pipes in Unix fulfil that role well. Processes (and more recently
threads) are also cheap and useful in Unix, again by design. You may
not like that design for some reason but there's nothing fundamentally
wrong with it, it's not "broken" and using that design as intended is
not a band-aid.

> Anyway, I am not sure your proposal is portable and it
> was probably just sci-fi 10 years ago. I do prefer my 10 years old hack.

It's portable to any system that supports POSIX.1c threads. A similar
solution (starting a thread to block for signals and notifying another
thread via a pipe) also works and is portable to anything which
supports POSIX.1c threads (including VMS and some other non-Unix
O/Ses). This is what perl uses to integrate signal handling with
threads when multi-threading.

> The problem of UNIX system API could have been that original designers
> only thought to files as generic O/S objects.

No, they thought of a global namespace of which the majority of
entries in practice are files but which can also contain things
like character devices and sockets.

> If they had thought to
> hamburgers instead, may-be they would have designed the thing a better
> way, since they couldn't miss the following:
>
> You can order your hamburger, then read your newspaper while somebody
> is preparing it, being sure that you will be told when your hamburger
> will be ready. And you also have the option to ask for the thing to
> be brought to you when ready. ;-)

Here in the UK we have a different system which corresponds more
closely to Unix, interestingly enough. When you order meals from a
counter which need to be prepared, they give you a sign or a piece of
paper with a number on it (let's call it a Food Descriptor, or "fd"
for short :-) and they make a note of the number on their piece of
paper. When the food is ready, they look at their piece of paper and
shout out the number. When you hear the number, you go up and get the
food. If I wanted to read the newspaper and not be constantly
listening, then I'd ask my son (let's call him a "child process" :-)
to listen out for it while I concentrated on the newspaper and ask him
to prod me when he heard the number. The good thing about Unix is that
it's very easy to create a child on the fly to tell you things like
that (although it's not quite as much fun as in real life).

That all seems like a perfectly good system to me. I'd certainly
rather not have a meal in a place where 90% of the staff are running
around trying to find people since the overhead of them doing that
will mean the meal will cost more and arrive more slowly (more staff
running around than cooking/preparing). Shades of other O/Sed, there.

--Malcolm

-- 
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/