#fork and deterministic resumption of the resulting process
siguctua at gmail.com
Tue Feb 5 21:48:11 UTC 2008
Let's look at the fork from theoretical POV, not practical implementation.
When developer puts fork in code, he supposing that execution will
spawn another, parallel process:
/-------- original process
\-------- spawned fork
Suppose, in ideal environment both processes start running in
parallel, and there is no scheduling, preemption and another gory
So, it's obvious: if you need some state to be consistent in both
execution threads, you should make sure to initialize it before fork
Andreas gave a good example of typical error, when you writing a
concurrent code: trying to initialize the state after doing fork,
making assumption that we not working under ideal environment and
bound solution to specific implementation (knowledge on how scheduler
Also, if changes, what Andreas proposed will take place, then fork
will be not a fork anymore (in original context), since it's semantics
puts much favor on execution of original process.
Also, in case when you will need/want to port your code on another
smalltalk dialect, your code have a good chances to not work
correctly. And if you may know, catching such errors can take a lot of
Igor Stasenko AKA sig.
More information about the Squeak-dev