Path: utzoo!mnetor!uunet!husc6!rutgers!cmcl2!brl-adm!umd5!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!uiucdcs!uiucdcsp!johnson
From: johnson@uiucdcsp.cs.uiuc.edu
Newsgroups: comp.lang.smalltalk
Subject: Re: Parallel processes in smalltalk
Message-ID: <80500026@uiucdcsp>
Date: 27 Jan 88 14:43:00 GMT
References: <2100@pdn.UUCP>
Lines: 22
Nf-ID: #R:pdn.UUCP:2100:uiucdcsp:80500026:000:1268
Nf-From: uiucdcsp.cs.uiuc.edu!johnson    Jan 27 08:43:00 1988


Problem: Smalltalk processes are nice on paper, but don't work well in
practice because the user-interface takes up all the CPU.
	"If the processes are forked at
	userinterface priority (with appropriate yields) then one can hardly
	get any mouse activity in edgeways. If the processes are forked at
	a higher priority, then one has to introduce suspensions (through
	Delay ... wait) which could spoil the co-ordinations. If the processes
	are forked at a lower priority than userinterface priority, then they
	don't run."

The solution is to fix the user-interface code, which is clearly designed
wrong.  Controllers poll the I/O devices; they should instead be interrupt
driven.  There is one fix short of rewriting all the controllers.  Find
the dozen or so places where controllers are looping, waiting for I/O.
In each loop, wait on a semaphore for an input event (see page 648 of the
blue book).  We did this on the Tektronix implementation and it works fine.
The only problem we had was that interrupts were not generated when the
mouse moved, even though the manual claimed that we could turn them on.
We got a new version of the interpreter and the problem was fixed.  I bet
that other interpreters might not be able to generate interrupts on mouse
movement.