From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-winken!uunet!mcvax!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.lang.ada
Subject: Re: O.S. support for lightweight processes
Summary: Use MACH, not POSIX...
Message-ID: <812@aber-cs.UUCP>
Date: 10 Apr 89 14:37:53 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Distribution: eunet,world
Organization: Dept of CS, UCW Aberystwyth
	(Disclaimer: my statements are purely personal)
List-Id: <comp.lang.ada>

In article <8904041419.AA00580@mbunix.mitre.org> emery@MBUNIX.MITRE.ORG (Emery) writes:

    Bob Hathaway (rjh@purdue.edu) writes:
    >I haven't looked at the POSIX standard yet but I'm hoping support
    >for lightweight processes and distributed programming is provided.
    
    The existing POSIX standard (P1003.1) does not include either
    lightweight processes or distributed programming.  Nor will it any
    time soon.  This is because the goal of the effort is to standardize
    existing practice.

Uhuhuh. Just like ANSI C, one can imagine :-> :->. Do I remember somebody
saying that all switches oops... options to POSIX commands will be case
insensitive so that POSIX emulation could be done painlessly under VMS
oops... single case based operating system environments, thus reversing
about twenty years of laudable dual case Multics/Unix tradition?

    There is no industry consensus on lightweight processes,

This could run for "understatement of the year". Most of the industry does
not understand or know about threads at all...

    the same way there is for other things, such as fork, signals, etc, in
    Unix.

The phrase "the same way" of course refers to "no consensus". Have you tried
porting programs between different versions of UNIXes? If so, you know how
much of a consensus exists even on basics... As to me, I know that often the
only portable subset if V7-signals+named pipes. All else is subject to much
doubt....

    (Note that the POSIX signal model is different from both System V and
    4.2 BSD, but not radically so.  The differences are in implementation.)

QED
    
    The POSIX Real-Time group (P1003.4) has been looking at threads, and
    MAY include a threads/lightweight process interface in its document.

The last thing a standards committee ought to do is design. The exceptions
(like the Algols) to the rule are very rare. Of course, if they take an
existing true and tried threads design (like MACH) and adopt it, that's
another matter.

    Although not a direct issue for the Ada binding, those of us working
    on the Ada binding would very much like to see a threads interface
    that can be used to implement Ada tasks.

Halleluia! Every Ada use would like to have true threads. All we have so
far almost everywhere is coroutines.
    
    I agree that current state-of-the-practice operating systems often get
    in the way of Ada, but don't look at a Standards activity to fix this
    problem until the state-of-the-practice is there.  

If only other people had been so restrained in the past, many troubles would
have been avoided. In this, I must reluctancly agree, the Ada standard fares
better than most (even if many argue that the introduction of the rendez
vous as the one IPC device was not based on start-of-the-art practice, and
it shows...).
-- 
Piercarlo "Peter" Grandi            |  ARPA: pcg%cs.aber.ac.uk@nss.cs.ucl.ac.uk
Dept of CS, UCW Aberystwyth         |  UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK  |  INET: pcg@cs.aber.ac.uk