l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Which 90% of POSIX /is/ good then?


From: Jonathan S. Shapiro
Subject: Re: Which 90% of POSIX /is/ good then?
Date: Thu, 27 Oct 2005 10:52:01 -0400

On Thu, 2005-10-27 at 12:34 +0200, Alfred M. Szmidt wrote:
> You cannot get away from race conditions,

This is only partly true.

It is true that you can't stop a programmer from screwing up if they are
determined to do so. But I would say that systems can be *subjectively*
characterized into three classes:

  1. Systems where avoiding race conditions is impossible
  2. Systems where avoiding race conditions is possible with
     extra work
  3. Systems where avoiding race conditions is a natural
     consequence of programming in the natural way.

Original UNIX was in the first category. POSIX also was in the first
category. Later enhancements are slowly moving UNIX-based systems into
the second category. KeyKOS is in the third category.

I say that this grouping is subjective because I cannot clearly
articulate the underlying design patterns that make race conditions
easily avoidable, and until I can do that I don't have a testable basis
for categorizing other than my own experience and the experience
reported by others.

> Race conditions cannot be fixed, no matter what kind of a API you
> implement.

I don't think this is true. Transactions go a very long way here. In any
case, what *is* true is that the *absence* of certain properties in an
API can make race conditions unavoidable.

>    * The unified file namespace is tied all together by ".." parent
>    acess and by symlinks relative to the root. (And now by shared
>    libraries for binaries) Separating out individual directories is
>    pretty pointless, and chroots are a pain to use. No chance of
>    security subdomains there.
> 
> This isn't a argument against what you call a unified file namespace,
> it is a argument against: badly written programs and chroot's.

Sorry. No. It is an argument against a bad (because it is unsatisfiable)
specification of the semantics of ".." by POSIX.

>    * File access API. Assumes most files are mutable. (clue: this
>    turns out to be wrong!) Ignores multiple versions. Destroys
>    transactional semantics by making files appear in filesystem on
>    open, instead of on close. Hello access to half-completed files!
>    Oh, wow, we do a get a transactional rename. Wot no metadata?
> 
> All of these has nothing to do with POSIX once again, you are free to
> implement a versioning file-system, add metadata etc, and it won't
> make the system a non-POSIX system.

Actually, the evidence of experience is that you can't implement a
reasonable versioning file system without significantly extending POSIX.
As Hans found out in ReiserFS and others discovered in JFS and XFS, you
also cannot do any reasonable transacted interface without significant
alterations to POSIX.

>    * fork: oh dear, it leaves all the fds open, signals enabled,
>    sessions wrong, uids gids etc. Its rarely what we actually
>    want. Most things just (forget to) close lots of things and exec
>    immediately.
> 
> So you blame incompetence instead of attacking the real faults with
> fork/exec.

This is not incompetence. The objection is to an API that is "fail open"
instead of "fail closed". In this regard, POSIX really is not well
designed, because it magnifies the likelihood of programmer error.


shap





reply via email to

[Prev in Thread] Current Thread [Next in Thread]