#fork and deterministic resumption of the resulting process
nicolas cellier
ncellier at ifrance.com
Thu Feb 7 20:43:45 UTC 2008
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.
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.
What matters is that code is bad today, because programmer expectations
do not meet Kernel implementation. And Andreas solved this nicely I think.
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.
Sorry, I don't like crying with the wolves, but your repeated assertions
deserved a response.
Friendly.
Nicolas
More information about the Squeak-dev
mailing list
|