On 05/02/2008, Andreas Raab <andreas.raab at gmx.de> wrote:
> Paolo Bonzini wrote:
> > I'm with Terry on the correct idiom to use, i.e.
> >
> >     workerProcess := [self runWorkerProcess] newProcess.
> >     workerProcess resume.
>
> Sigh. One of the problems with examples is that they are ... well
> examples. They are not the actual code. The above solution is simply not
> applicable in our context (if it were, I would agree with it as the
> better solution).
>

Andreas, you looking at problem from wrong angle, i think.
Even in C you have separate thread creation and it's resuming:
(this code if from socket plugin win32 platform code)
-----
  asyncLookupHandle =
    CreateThread(NULL,                    /* No security descriptor */
                 0,                       /* default stack size     */
                 (LPTHREAD_START_ROUTINE) &sqGetHostByName, /* what to do */
                 (LPVOID) PLUGIN_IPARAM,       /* parameter for thread   */
                 CREATE_SUSPENDED,        /* creation parameter --
create suspended so we can check the return value */
                 &id);                    /* return value for thread id */
  if(!asyncLookupHandle)
    printLastError(TEXT("CreateThread() failed"));
  /* lookups run with normal priority */
  if(!SetThreadPriority(asyncLookupHandle, THREAD_PRIORITY_NORMAL))
    printLastError(TEXT("SetThreadPriority() failed"));
  if(!ResumeThread(asyncLookupHandle))
    printLastError(TEXT("ResumeThread() failed"));
-----
See, first you obtain handle, do checks, setting it's priority e.t.c,
and only then issue ResumeThread() to enable it running.

So, why in smalltalk things should look different?
The point is, that once you enabling process to run, you can't
guarantee that current process will continue running and will not be
preempted by forked one.
And making changes to get favor of one execution thread over another
will not solve the problem, because your solution may fit for your
purposes, but don't fit for others.

Simply don't assume that any bit of code having chance to be executed
in process which created new process by issuing #fork before forked
process is actually started execution.


> [BTW, I'm gonna drop out of this thread since it's clear that there is
> too much opposition for such a change to get into Squeak. Which is fine
> by me - I'll wait until you will get bitten in some really cruel and
> unusual ways and at that point you might be ready to understand why this
> fix is valuable. Personally, I think that changes that take out an
> unusual case of non-determinism like here are always worth it - if
> behavior is deterministic you can test it and fix it. If it's not you
> might get lucky a hundred times in a row. And in the one critical
> situation it will bite you].
>
> Cheers,
>    - Andreas
>
>
>


-- 
Best regards,
Igor Stasenko AKA sig.