(I'm broadening the discussion to include haskell-cafe.)<br><br>Andy -- What do you mean by "handling all thread forking locally"?<br><br> - Conal<br><br><div class="gmail_quote">On Thu, Dec 18, 2008 at 1:57 PM, Andy Gill <span dir="ltr"><<a href="mailto:andygill@ku.edu">andygill@ku.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style="">Conal, et. al,<div><br></div><div>I was looking for exactly this about 6~9 months ago. I got the suggestion to pose it as a challenge</div>
<div>to the community by Duncan Coutts. What you need is thread groups, where for a ThreadId, you can send a signal</div><div>to all its children, even missing generations if needed. </div><div><br></div><div>I know of no way to fix this at the Haskell level without handling all thread forking locally. </div>
<div><br></div><div>Perhaps a ICFP paper about the pending implementation :-) but I'm not sure about the research content here.</div><div><br></div><div>Again, there is something deep about values with lifetimes. </div>
<div><br></div><div>Andy Gill</div><div><br></div><div><br><div><div><div><div></div><div class="Wj3C7c"><div>On Dec 18, 2008, at 3:43 PM, Conal Elliott wrote:</div><br></div></div><blockquote type="cite"><div><div></div>
<div class="Wj3C7c">I realized in the shower this morning that there's a serious flaw in my unamb implementation as described in <a href="http://conal.net/blog/posts/functional-concurrency-with-unambiguous-choice" target="_blank">http://conal.net/blog/posts/functional-concurrency-with-unambiguous-choice</a>. I'm looking for ideas for fixing the flaw. Here's the code for racing computations:<br>
<br><span style="font-family: courier new,monospace;"> race :: IO a -> IO a -> IO a</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> a `race` b = do v <- newEmptyMVar</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> ta <- forkPut a v</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> tb <- forkPut b v</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> x <- takeMVar v</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> killThread ta</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> killThread tb</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> return x</span><br style="font-family: courier new,monospace;">
<br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> forkPut :: IO a -> MVar a -> IO ThreadId</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> forkPut act v = forkIO ((act >>= putMVar v) `catch` uhandler `catch` bhandler)</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> where</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> uhandler (ErrorCall "Prelude.undefined") = return ()</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> uhandler err = throw err</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> bhandler BlockedOnDeadMVar = return ()</span><br>
<br>The problem is that each of the threads ta and tb may have spawned other threads, directly or indirectly. When I kill them, they don't get a chance to kill their sub-threads.<br><br>Perhaps I want some form of garbage collection of threads, perhaps akin to Henry Baker's paper "The Incremental Garbage Collection of Processes". As with memory GC, dropping one consumer would sometimes result is cascading de-allocations. That cascade is missing from my implementation.<br>
<br>Or maybe there's a simple and dependable manual solution, enhancing the method above.<br><br>Any ideas?<br><br> - Conal<br><br><br></div></div> _______________________________________________<br>Reactive mailing list<br>
<a href="mailto:Reactive@haskell.org" target="_blank">Reactive@haskell.org</a><br><a href="http://www.haskell.org/mailman/listinfo/reactive" target="_blank">http://www.haskell.org/mailman/listinfo/reactive</a><br></blockquote>
</div><br></div></div></div></blockquote></div><br>