emery@MBUNIX.MITRE.ORG (Emery) (04/04/89)
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. There is no industry consensus on lightweight processes, the same way there is for other things, such as fork, signals, etc, in Unix. (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.) The POSIX Real-Time group (P1003.4) has been looking at threads, and MAY include a threads/lightweight process interface in its document. 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. Besides making the Ada RTS implementor's life easier, hopefully the threads interface would provide for single-level scheduling of all threads (both POSIX/C threads and Ada tasks) across the entire system. 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. Dave Emery emery@mitre.org POSIX Ada Binding (P1003.5) Technical Co-Editor p.s. If you believe this is a "good thing", then consider joining the POSIX effort, either the working group or the balloting group.
pcg@aber-cs.UUCP (Piercarlo Grandi) (04/10/89)
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