2009/10/15 Holger Hoffstätte <span dir="ltr"><<a href="mailto:holger.hoffstaette@googlemail.com">holger.hoffstaette@googlemail.com</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
</div>In Java you will _always_ end up with at least one thread per *concurrent<br>
activity* since Java does not have continuations - the ability to freeze a<br>
running activity in-flight and resume it later. For that you need a<br>
user-level activity scheduler and some form of compiler or byte code<br>
weaving support.</blockquote><div><br></div><div> I'm not sure I see how this is relevant - queueing of requests and processing by a fixed sized thread pool, or pool dynamically sized to the backlog of work in the queue, is fine in the majority of cases. If you split up the tasks into appropriately sized Runnables which queue their successors in the pool, things should run quite smoothly. Yes, it's not as automatic as microthread implementations like Kilim offer, but I find it does make you think more carefully about how to logically deconstruct the task flow.</div>
<div><br></div><div>Iain</div><div><a href="http://www.onedrum.com">www.onedrum.com</a></div></div>