"dremon" <
[hidden email]> wrote in message
news:
[hidden email]...
> Hello,
>
> Who can explain me the following thing: when I'm forking a new process
> with the same priority as main (5), which loads processor for 100%, the
> Dolphin IDE stops responding. I found an explanation that a given
> process has to call yield method in order for other processes with the
> same priority to get CPU time, BUT! When I tried to fork two processes
> with priority 4 - both of them where using CPU even without any yield
> calling. Why this is not the case for main process?
Because other higher priority processes (such as the main UI process) will
pre-empt any lower priority process. When a process is pre-empted, it is
sent to the back of the queue at its priority level. Consequently when the
processor again makes time available to the lower priority processes a
different one will get a chance.
In other words Smalltalk (well at least Dolphin) does already pre-emptively
multitask, it just doesn't timeslice. You can implement a quick'n'dirty
timeslicing mechanism very easily by starting a high priority process that
wakes periodically to to give the process system a prod now and again. For
example:
slicer := [[Processor sleep: 50] repeat] forkAt: Processor
interruptPriority
You should now be able to start a CPU hogger...
hogger := [[Object withAllSubclasses asSortedCollection] repeat] fork
... and find that the IDE still responds. However it will be sluggish in a
familiar sort of way. So reminiscent in fact, of the behaviour of a certain
well-know operating system, that it makes one wonder if this isn't the basis
of its own timeslicing mechanism :-).
Of course most of the sluggishness can be avoided by forking the hogger at a
lower priority, or by lowering its priority...
hogger priority: Process userBackgroundPriority
In which case you won't need the slicing task.
Regards
Blair
Locked
