[squeak-dev] Process bug introduced in 3.10

Igor Stasenko siguctua at gmail.com
Sat Apr 26 22:37:54 UTC 2008


I removed the MessageTally  and added outer fork , just to not lock ui
when test running. Everything works fine.

| processes |
[
100 timesRepeat:
       [processes := (1 to: 10) collect: [:each|
		[ [ ((Delay forMilliseconds: 500) wait) ] repeat ] fork ].
       (Delay forSeconds: 1) wait.
       processes do: [:each| each terminate].]

] fork

In your test, a MessageTally will pop up a zeons windows, do you
really think its needed to be placed in test?
I suspect that it can work fine, but because of too many morphs
created it either run out of memory or spends too much time trying to
redraw screen. Also, since morphic was not designed with concurrency
in mind, adding morphs to world from different processes may lead to
race and damage different containers it using.


2008/4/27 Igor Stasenko <siguctua at gmail.com>:
> 2008/4/27  <bryce at kampjes.demon.co.uk>:
>
>
> >
>  >  Run the following in a 3.10 image:
>  >    100 timesRepeat:
>  >         [processes := (1 to: 10) collect: [:each| [[(MessageTally spyOn: [(Delay forMilliseconds: 500) wait]) ] repeat] fork ].
>  >         (Delay forSeconds: 1) wait.
>  >         processes do: [:each| each terminate].]
>  >
>  >  It locks up the image, debuggers will start popping up at some stage.
>  >  This works on 3.9. I've run the code above in a fresh 3.10 image and
>  >  reproduced the problem.
>  >
>  >  I'll try to find time to investigate further. It's probably the final
>  >  showstopper to me upgrading to 3.10. The code above is reworked from
>  >  on of Exupery's SUnits which locks up the image intermittently.
>  >
>
>  AFAIK, since 3.9 there was some fixes in Delay & Semaphores.
>  Its hard to say, if its a new bug in Delay or Process & scheduler or
>  this is remnants of code (in MessageTally) which was not fixed and
>  relies on old behavior.
>
>  As for me, its no wonder, that given code refuses to work correctly.
>  The implementation of Processes and all what is around them is very
>  brittle, and given stress test exposing this. As you know there are
>  different hacks & workarounds to keep things running without modifying
>  VM.
>  Thanks for giving another reason why squeak threading model requires
>  serious review. :)
>
>  >  Bryce
>  >
>  >
>
>
>
>  --
>  Best regards,
>  Igor Stasenko AKA sig.
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list