ard@pdn.UUCP (Akash Deshpande ) (01/26/88)
How could one elegantly monitor the progress of parallel processes
spawned in a smalltalk application? This could be necessary while
developing an application, when it is useful to have the full smalltalk
development environment around. 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.
Possibly, the yield function could be modified slightly to cause
minor suspensions of the receivers. Ideally, such details should not
be addressed by the programmer but managed by the system itself.
This can be done if multiple instances of Processor can be created
(with some internal mapping to the physical processor). Of course,
the development can be brute-forced by writing debugging messages
to some structures and later reading them, etc.
Comments and discussion appreciated.
--------------------------------------------------------------------------
Akash Deshpande
{gatech,rutgers,attmail}!codas!pdn!ken Mail stop LF-207
Phone: (813) 530-8307 P.O. Box 2826
Largo, FL 34649-9981
"The views expressed above do not necessarily reflect the views of my
employer, which by no means makes them incorrect."johnson@uiucdcsp.cs.uiuc.edu (01/27/88)
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.