<br><br><div class="gmail_quote">On Tue, Aug 7, 2012 at 1:45 PM, Jeff Darcy <span dir="ltr"><<a href="mailto:jdarcy@redhat.com" target="_blank">jdarcy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, 7 Aug 2012 20:13:35 +0200<br>
<a href="mailto:manu@netbsd.org">manu@netbsd.org</a> (Emmanuel Dreyfus) wrote:<br>
<div class="im"><br>
> Anand Avati <<a href="mailto:anand.avati@gmail.com">anand.avati@gmail.com</a>> wrote:<br>
> What was behind the decision to use swapcontext, btw? Why not just<br>
> have a thread for each task?<br>
<br>
</div>I should probably let the authors speak for themselves, but I suspect<br>
it's because operations like self-heal and rebalance can be expected to<br>
generate a *lot* of sync calls. Threads do still consume non-trivial<br>
resources, and switches between them still involve a trip through the<br>
scheduler, even if they share an address space etc. I just ran a quick<br>
experiment, and ping-ponging between tasks via swapcontext was ~9x as<br>
fast as via pthreads. I didn't measure the effect on memory<br>
consumption, but it's likely to be at least as large as the effect on<br>
execution time.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>That is largely the right reason. Pthreads are much more expensive than context based "threads".</div><div><br></div><div>Avati </div>
</div>