More multitasking (was: Re: Background tasks slow UI?)

Rob Withers rwithers12 at mediaone.net
Sun Sep 16 02:13:17 UTC 2001


Scott, did you say no, it can't be done? :-)     I agree with all that you have said, especially keeping the concurrency out of all the other code.  I also agree with the link you provided.   It also mentions the areas where it is useful to do concurrency.  As your example points out, there are good reasons for having multitasking, but difficult to do in a safe way.  It's a bitch!  Programming UI applications shouldn't have to deal with multiple processes (threads, tasks).  We don't have to in squeak because of the wonderful stepping engine, which drives Morphs, Scripts, Wonderland, Sockets.  We should be able to come up with a good simple mechanism to allow for concurrency, without compromising either safety or responsiveness.

We have cooperative multitasking, where another process at the same priority won't interrupt the running process.  I should have stated that I was interested in time-slicing.    

Let me simply state what capability I would like.   I want to enable background processing, and foreground stepping, without affecting the responsiveness of the UI.   Many background tasks can be long running, which would freeze the UI if they are at a higher or equal Priority.  Even step methods can be long running, thus starving other steppers.  If we process with time-slicing and use a good event model, we could move many tasks into the background, and even if they are higher priority and long running, we could time-slice enough to remain responsive.  The async code I posted recently handles the async events between processes.   My Task code does something very similar to the TCL event loops.

Seeing IO occur without busywaits is also desirable, although contrary evidence has been posted.  Blocking IO is a cleaner design, and we can gain asynchronous IO by registering a callback (#when:asend:to:) which would be activated in the Morphic Process.  This would maintain thread safety, as long as different threads didn't access the same object.  

Part of the desire for this is for scientific applications, like the biosqueak effort.  Imagine the we could each offer 10% of our processor to a distributed task server, and we could each submit tasks for long running computation.  I would love to offer some of my machine, but I want it to be safe and non-invasive to my work.  This says sand-baxed and time-boxed, to me.  Is there an easier way to gain these features?

- Rob


More information about the Squeak-dev mailing list