On 07/02/2008, nicolas cellier <ncellier at ifrance.com> wrote:
> Michael van der Gulik a écrit :
>
> > Andreas is a great programmer, but the example he posted had a bug in
> > it and the proposed fix was incorrect.
> >
>
> The patch is correct in its Squeak context.
>
> A feature taken for granted by many programmers as indicated by existing
> code base was working in 99.9%, but was not guaranteed 100%.
>
> If this feature seems natural and its implementation does not break
> anything, why not change the API and make it conform to common expectations?
>
> Andreas either added a new contract, or repaired a broken contract.
>
Please, correct me if i'm wrong:
Andreas proposing that given code will work

workerProcess := [ ... ] fork.

while in block, you accessing a workerProcess variable and expect it
to be initialized.

Now, if that's true, then some of us might assume that he can do
something like this:

MyClass>>forkAndReturnForkedProcess

^ [ .... ] fork.

and in another method write:

MyAnotherClass>>forkProcess
^ forkedProcess := myClass forkAndReturnForkedProcess.

and he should expect that this should work as well?

And then, third developer cames and writes another method , which
relies on such behavior and so on..
So, where this 'determinism' chain can be stopped, where you don't
have any guarantees if forked process accessing
initialized/uninitialized state?
How i can estimate, where to stop with such kind of determinism?
Isn't it would be better to have 'determinism' in following: if you
forked process, you should make sure that you have everything properly
initialized before doing fork?

> Your concerns are about
> - portability to other dialect
> - compatibility with future parallel thread
>
> The first might not be major, other Smalltalk can be patched too (if
> needed).
>
> The second cause is noble, but maybe not wise, you are putting too much
> constraints on code for an eventual event that might not happen any time
> soon. How can you foresee an API that still isn't defined? And if you
> can, can we?
> A french would call that "tirer des plans sur la comète".
>
>
> > I'll continue this discussion after I've released a stable,
> > multi-threaded VM in which Andreas's example breaks.
> >
> > Gulik.
> >
>
> With different API contracts and constraints a lot of code would break.
>
> Either, there will be a major rewrite of libraries, or you will have to
> provide a backward compatibility for elder API.
>

Hmm, why we should pursue with major rewrite each time?
Why don't call it #determinatedFork (or whatever) and don't touch
original method?

> What matters is that code is bad today, because programmer expectations
> do not meet Kernel implementation. And Andreas solved this nicely I think.
>
I don't agree with that. I never expected that fork should work as
Andreas proposing.

> Maybe we are all wrong because you are able to provide a clever
> concurrent parallel multithread implementation 99% compatible with
> existing code base, even core BlockContext and Process class, maybe you
> are a few years ahead, but until this is proven, we'll assume Andreas is
> right.
>

I don't think it's the case, where we need to break compatibility.


> Sorry, I don't like crying with the wolves, but your repeated assertions
> deserved a response.
>
> Friendly.
>
> Nicolas
>

And finally, do you really think, that hiding concurrency issues from
the eyes of developer helps him to write good thread-safe code?
I think, it's doing exactly opposite: makes him think safe and comfortable.
But then, where problem fill finally knock to his door, he will not
know what to do, because API having only 99% guarantees of something
that it will work, leaving 1% to whom???


-- 
Best regards,
Igor Stasenko AKA sig.