Path: utzoo!mnetor!uunet!oresoft!randy
From: randy@oresoft.UUCP (Randy Bush)
Newsgroups: comp.lang.misc
Subject: Re: Modula-2 Process Scheduling Design Error
Message-ID: <130@oresoft.UUCP>
Date: 29 Mar 88 16:17:26 GMT
References: <4538@xanth.cs.odu.edu>
Reply-To: randy@oresoft.UUCP (Randy Bush)
Organization: Oregon Software, Portland OR
Lines: 30
Keywords: reference SIGPLAN notices
Summary: That's a trivial library module, not the language

In article <4538@xanth.cs.odu.edu> kent@xanth.UUCP (Kent Paul Dolan) writes:
>I'd just like to direct the readership's attention to the March 1988
>SIGPLAN Notices, which has two useful Modula-2 articles.
>The first is "Unfair Process Scheduling in Modula-2", and points out a
>flaw in the semantics of the "send" command as it interacts with the
>usual (recommended by Wirth) single ready-run process scheduling ring
>of most (all?) Modula-2 implementations.  This looks a lot like a
>"gotcha!" if you are really using M2 for a multiple process tasking
>system.

This article points out one of the well-known flaws in a trivial
scheduler library module which was put in the book for tutorial purposes
only, not a flaw in the coroutine mechanism of the language.

I am not aware of anyone ever trying to use that module for anything
serious.  If you hear of such, tell them not to.  Take a look at Jirka
Hoppe's Nucleus instead.  Actually, everyone I have met who is doing
'real' process models is rolling their own from NEWPROCESS, TRANSFER,
and some interrupt mechanism such as IOTRANSFER.  That's what's nice
about a language where one is given the primitives, not someone else's
preconceptions of what's right for you.

So, in summary,

It does not seem to look like a gotcha for those of us who are using M2
for a multiple process tasking system.
-- 
randy@oresoft.uu.net                                          FidoNet:1:105/6.6
randy%oresoft.uu.net@relay.cs.net                             +1 (503) 245-2202
{ ..!mcvax!uunet, ..!textronix, ..!sun!nosun } !oresoft!randy