#fork and deterministic resumption of the resulting process

Igor Stasenko siguctua at gmail.com
Wed Feb 6 22:16:06 UTC 2008

On 06/02/2008, nicolas cellier <ncellier at ifrance.com> wrote:
> Michael van der Gulik a écrit :
> > Er... I can't tell if you're joking or if you're serious.
> >
> > I always write my code under the assumption that some day, in the
> > future, some bright spark will write a better VM that will run
> > separate Smalltalk Processes on separate OS processes/threads by
> > whatever means, thus better utilising multi-cored or multiple CPUs.
> >
> > When that day comes, my code will run faster and your code will break.
> >
> I see, sustainable development. Your writing code for our children.

Oh, come on, how you can be so blind?
You need a ground, based on which you can build your application.
You need some API with clear rules for play.
And these rules defined by shared principles and common terms, easily
understandable by people.
Newcomer who will start doing things should not spend time harvesting,
how #fork works on particular squeak version.

So, when i say, #fork, it should fork today, and should fork tomorrow,
and should fork after 20 years. Because it's a generic rule, and API
should behave as generic rule dictates: do whatever it take to make
two processes run in parallel.
But if you start doing reverse: let API influence rules, then what you
will get in result?
10 APIs and each defining own semantics of fork?

Best regards,
Igor Stasenko AKA sig.

More information about the Squeak-dev mailing list