<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Aug 24, 2013 at 3:26 PM, bearophile <span dir="ltr"><<a href="mailto:bearophileHUGS@lycos.com" target="_blank">bearophileHUGS@lycos.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">David Nadlinger:<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It's a cute idea, but not really practical, I'm afraid – Goroutines are managed by a scheduler in the Go runtime library, whereas D threads directly map to OS threads.<br>
</blockquote>
<br></div>
Can't Rory McGuire add a scheduler to his code? How much code does it take?<br>
<br>
Bye,<br>
bearophile<br>
</blockquote></div><br></div><div class="gmail_extra">I imagine that it will be fine on Linux because threads truly are lightweight on Linux, but its not going to be great on windows.<br><br></div><div class="gmail_extra">
Go's scheduler is basically the same as the way vibe.d works. Fibers. I haven't tried it but I could use fibers to do the same sort of thing, though it would be easiest to use in Vibe.d because even in go you have to do something that will wait/sleep in order to have your program advance unless you set GOPROCS to  a value greater than 1. Go's scheduler is not preemptive so there are the equivalent of Fiber.yield() spread throughout the standard library, I think.<br>
<br></div><div class="gmail_extra">I'm not sure how threads + fibers would have to interact in such a system.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>