Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!sri-unix!sri-spam!ames!ucbcad!ucbvax!SUN.COM!crb From: crb@SUN.COM (Chuck Bilbe) Newsgroups: comp.lang.modula2 Subject: Coroutines vs. Operating Systems Message-ID: <8611201656.AA00169@odysseus.sun.uucp> Date: Thu, 20-Nov-86 11:56:44 EST Article-I.D.: odysseus.8611201656.AA00169 Posted: Thu Nov 20 11:56:44 1986 Date-Received: Thu, 20-Nov-86 23:08:30 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 78 In the course of implementing the Modula-2 language on the Sun workstation under the Unix (TM) operating system, I have been faced with the problem of how to deal with the coroutine mechanism (Wirth's PROCESS type). There are a couple of aspects of the mechanism as I understand it which just don't lend themselves to an obvious interpretation in an environment like this. Specifically, I am looking for your input on the meaning of process priorities ( syntax "MODULE" "[" "]" ";" ) and the IOTRANSFER procedure on a system like Unix where programs outside the kernel cannot access hardware, prevent interrupts, or change machine interrupt response priority levels. The following approaches suggested themselves to me, but undoubtedly there are many others: A . Go ahead and generate code for the bare-bones machine, force the user to go through the process of linking kernel-mode code, and make NEWPROCESS, TRANSFER, and IOTRANSFER part of a nonstandard Unix kernel. Although to the uninitiated, this might look like just what the doctor ordered, it's much easier said than done, and the risks are immense. It becomes very difficult to manage the asynchronism between new releases of the operating system and any updates to the compiler. B . Take the other extreme and forbid process priorities and the IOTRANSFER procedure altogether; Implement NEWPROCESS and TRANSFER only, don't let Unix know that the stack pointer of the process is being played with, and let the code run entirely in user mode. It is now easy to share an address space between coroutines, because all coroutines in the user's Modula-2 program are a single Unix process. I get the feeling that this is what Dr. Wirth would recommend, as he states (ed. 1 & 2 PIM2) that the IOTRANSFER procedure is PDP-11 specific. It has the disadvantage that Modula-2 programs cannot do explicit rescheduling of other coroutines based on asynchronous external events. C . Use IOTRANSFER as a mechanism for waking up a coroutine on a Unix signal, treating Unix signals as if they represented the hardware interrupts implied by IOTRANSFER. Mask and unmask these signals as implied by coroutine priorities, assigning to each of the huge multitude of Unix signals its own priority level, in some arbitrary order. Note that with this implementation, the entire family of coroutines will still go "to sleep" if one of them performs a system call like "read", for example. Another difficulty is the time-dependent and non-atomic interactions between signals and Unix processes. Finally, Modula-2 programs wouldn't work well in harmony with C functions that play with signals outside the domain of the Modula-2 compiler. D . Assert that the coroutine abstraction isn't very useful if you already have a more powerful operating system, and instead let the users use the ordinary "fork/exec" mechanism to create "real" Unix processes. Leave NEWPROCESS, TRANSFER, and IOTRANSFER out altogether, or let users build them themselves. In the 1.0 implementation of Modula-2 on Sun, recently introduced, I have chosen approach B because it involves the least risk and provides reasonable functionality while allowing migration to the other alternatives later if that looks advisable. If I get significant levels of consensus from you users out there, it is probable that our implementation can be enhanced in the future. Fire away, and thanks in advance! Chuck Bilbe cbilbe@Sun.COM Project Leader, Modula-2 Sun Microsystems, Inc. Mountain View, CA.