"Hrefna Guðmundsdóttir" wrote:

> On Tuesday, January 19, 1999 3:32 PM, tim at jump.net [SMTP:tim at jump.net]
> wrote:
> > Hi, Jens -- you wrote:
> > > Anyway, when I try something that loops for some time, everything locks
> up
> > > until the loop finishes. I'm doing this from the Workspace and
> outputting
> > > to Transcript. Might I be doing something wrong or is Squeak just a
> single
> > > thread that vanishes into every object you call and you can't do a
> thing
> > > until it comes back (sort of)? If this is so, is it impossible for me,
> for
> > > example, to start two objects one after the other and in the mean time
> do
> > > something else until they finish their work? What I really like to be
> able
> > > to do is to send messages to objects and forget about the whole thing;
> the
> > > objects will take care of them selves and I don't have to hang around
> > > waiting for an answer.
> >
> > Squeak uses cooperative multitasking to run various processes
> "concurrently".  In this scheme, each process runs until it explicitly
> yields the processor.  Take a look at the Kernel-Processes classes (Delay,
> Process, ProcessorScheduler, Semaphore) for more info.

That's not true.  Squeak's threads are scheduled by a real-time policy, co-operative within the _same_ priority, but pre-emptive between threads of _different_ priority.  This policy is used for real-time systems because it gives precise control over scheduling; higher priority threads are never pre-empted by the end of a time slice, but within a priority threads can decide when they wish to yield to others.

With this Squeak/Smalltalk scheduler one can implement a time slicing scheme above it; e.g. have a high priority process waiting on a delay that time slices some set of lower priority processes.  One can't do the reverse and implement a real-time scheduler above a time sliced one; i.e. the Squeak/Smalltalk scheduler is well chosen as the fundamental scheduler.

> >
> > One way to do what you want (run a concurrent process in the background)
> is to put what you want to do in a block, including a Processor yield or
> delay in the loop (to allow other processes time to run), and fork it as a
> new process.  For example:
> >
> > [1 to: 50 do: [:i | Transcript show: i printString; cr. (Delay
> forSeconds: 2) wait]] fork.
> >
> >
> > Hope that helps,
> >
> >       -- Tim Olson
> >
>
> Thanks. I think I can use this, but it reminds me of the 'dark ages' of
> Windows 3.x, where badly written apps 'stole' the processor :)
>
> Why was multitasking in Squeak done this way? Is there any hope that real
> threads (at least green ones) will be implemented?
>

That's not the issue.  Squeak, and Smalltalk in general, _does_ have green threads.  The issue is that the UI hasn't been written to be multi-threaded.  And if one does make the UI multi-threaded then one will have to consider what else in the system needs to be made thread safe, e.g. compiling, adding/removing methods, etc, none of which is currently thread safe.

The current scheduling policy of being co-operative within a priority means that UI developers have been able to ignore thorny thread safety  issues.  This is one of the reasons the Squeak/Smalltalk UI has evolved so fast and so interestingly. Think hard before you introduce the complexity of a thread safe system.


_______________,,,^..^,,,_______________
Eliot Miranda, ParcPlace