On 03/03/2008, Paolo Bonzini <bonzini at gnu.org> wrote:
>
>  >   BlockContext>>fork
>  >       "Create and schedule a Process running the code in the receiver."
>  >       self newProcess resume.
>  >         ^ nil
>  >
>  > These changes will stop forks from being used in wrong manner and
>  > effectively eliminate the problem of "letting fork initiator process
>  > to run little bit more to assign returned value anywhere".
>
>
> I sort of agree (at least on the intent, of course this will break
>  code).  However, I will point out that problematic uses are only those
>  who use the #fork return value in a different, already running process.
>
>  For example, this code is tricky but not racy, because the second
>  process isn't started until delayProcess is assigned:
>
>      delayProcess := [
>         (Delay forMilliseconds: msec) wait.
>          sema signal.
>          Processor activeProcess suspend ] fork ].
>
>      [[aBlock value] ensure: [delayProcess terminate. sema signal]] fork.
>      sema wait.
>
>  but with the sort-of-proposed change to #fork the user could be tempted
>  to write it like this:
>
>      [
>         delayProcess := Processor activeProcess.
>         (Delay forMilliseconds: msec) wait.
>          sema signal.
>          Processor activeProcess suspend ] fork ].
>
>      [[aBlock value] ensure: [delayProcess terminate. sema signal]] fork.
>      sema wait.
>
>  and the latter *is* racy.
>

In this case, i would tell people to read something about Concurrent
Programming before try any coding.

Oh, i giving up. All these patches failing into category: 'selling 2
wheeled bike with 3rd wheel mounted for safety'.
There is little you can do to help people writing good concurrent code
by providing such patches which hiding problems under the hood.
Programmer is not a baby who needs to wear Pampers.

>
>  Paolo
>
>


-- 
Best regards,
Igor Stasenko AKA sig.