Processes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Processes

Stefan Izota
Hi all,

I'm a little confused about processes.

I entered the code
[10 timesRepeat: [Transcript show: '1'. Processor yield]] fork.
[10 timesRepeat: [Transcript show: '2'. Processor yield]] fork
in the file "DummyProcesses.st" and ran with "gst DummyProcesses.st".
The result is what I have expected:
12121212121212121212

If I change the code with
[10 timesRepeat: [Transcript show: '1'. (Delay forMilliseconds: 1)
wait]] fork.
[10 timesRepeat: [Transcript show: '2'. (Delay forMilliseconds: 1)
wait]] fork
and run it again I get different results. Like
12
or
121
or
1212
, etc.

If I add
(Delay forMilliseconds: 100) wait
and run it, the two processes finish with different result every time.

Am I doing something wrong or this should be the right behavior?


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Processes

Paolo Bonzini-2
> If I change the code with
> [10 timesRepeat: [Transcript show: '1'. (Delay forMilliseconds: 1) wait]]
> fork.
> [10 timesRepeat: [Transcript show: '2'. (Delay forMilliseconds: 1) wait]]
> fork
> and run it again I get different results. Like
> 12
> 121
> 1212
>
> If I add
> (Delay forMilliseconds: 100) wait
> and run it, the two processes finish with different result every time.
>
> Am I doing something wrong or this should be the right behavior?

Whenever the execution finishes for what you typed at the REPL, the
other processes are suspended and another "st>" prompt is displayed.
Since there's nothing after the second fork, as soon as both processes
are waiting on a delay, the REPL process will terminate.  This will
happen very soon, after 1 or 2 iterations in general.  Adding a 100 ms
delay ensures that your two processes finish, so yes, this is the
right behavior.

If by "different result every time" you mean that you get some
"1221211" results, this is also expected.  The reason is that your
delays are very short, comparable with the timer resolution.  So, it's
likely that both timers will wake up at the same millisecond clock
value; which one will be picked first is substantially random.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk