Thanks Bulat. What you wrote makes perfect sense to me. However under 6.10.4 this is what I observed. Pseudo code:
c = l++r `demanding` l>||r then th <- forkIO (c `seq` return ()) Run it the first time to completion and watch two cores turn at better than 95% utilisation, quite pleasing. Run it the second time and half way through the calculation use killThread th and watch one core become idle and one core turn at better than 95%. Wait until the first core finishes and then use c and watch the rest of the calculation finish. Now, what you wrote and this experiment tells me that l was sparked and then given a free thread in which to calculate. r was still in the original thread of execution of the forkIO and therefore was affected by the killThread th whereas l was not. Does this read correct to you? If so, then I understand! Thanks, - Marcus Bulat Ziganshin wrote: > Hello Marcus, > > Sunday, December 20, 2009, 4:17:26 PM, you wrote: > > par adds so-called spark to the queue of calculations to proceed. once > RTS has free thread, this thread starts to calculate the spark. it has > no communication with thread that created the spark. when calculation > is completed, its thunk will be updated with result of calculation (as > usual in lazy calculations). so killing originator thread doesn't > affect all the sparks it has created, it only prevents generation of > new sparks. -- Marcus D. Gabriel, Ph.D. Saint Louis, FRANCE http://www.marcus.gabriel.name mailto:mar...@gabriel.name Tel: +33.3.89.69.05.06 Portable: +33.6.34.56.07.75 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users