#fork and deterministic resumption of the resulting process
Michael van der Gulik
mikevdg at gmail.com
Wed Feb 6 22:38:43 UTC 2008
On 2/7/08, Igor Stasenko <siguctua at gmail.com> wrote:
> 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?
Sig: I think that people are now just saying rubbish to provoke a
reaction. I wouldn't bother replying.
More information about the Squeak-dev