<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br><div><div>On Jan 22, 2008, at 6:02 PM, Matthew Fluet wrote:</div><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">Under the current runtime, much of the thread code is implemented in SML. What does it mean that 'the thread code is all external'?</span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div></blockquote><div><br class="webkit-block-placeholder"></div><div>The scheduler I wrote is entirely in C. It provides M:N scheduling using completely lock-free algorithms (the ultimate aim is to combine this with GC-allocated frames and other mechanisms with the hope of bringing thread-creation overhead down to some small multiple of a function call) The threading library on the SML side will be mostly a wrapper.</div><div><br class="webkit-block-placeholder"></div><div>There's two reasons for this being written in C:</div><div><br class="webkit-block-placeholder"></div><div>1) With a parallel garbage collector, you have to invoke the scheduler to run the collector, which ends up creating problems if the scheduler allocates from the collector. There are ways around this, but they get nasty, and...</div><div><br class="webkit-block-placeholder"></div><div>2) It's easier to make the scheduler system completely free of locks this way. Aside from scaling to large numbers of processors, doing this has the benefit of being able to freely create threads in an asynchronous context, et cetera.</div><div><br class="webkit-block-placeholder"></div><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">Testing with MLton-compiled SML programs or testing with a scheduler specific harness?</span></div></blockquote><br><div>I have an artificial program which randomly creates and destroys threads.</div><br><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">I know that your project has been a "standalone runtime for concurrent functional languages", with the hope that it could serve as an alternate runtime for MLton.<span class="Apple-converted-space"> </span>I'm simply curious about the extent to which it has actually been integrated with MLton (or MLton integrated with it).</div> </blockquote></div><br><div>I'll be integrating once I finish the collector itself. I'll probably also write a simple random test program for the collector and the malloc implementation. I'm aiming to start some of the integration next week, when the collector is mostly written.</div><br><div> <span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div>-- </div><div>Eric McCorkle</div><div>Brown University</div><div>CS Graduate Student</div><br class="Apple-interchange-newline"></span> </div><br></body></html>