<div class="gmail_quote">On Fri, Feb 27, 2009 at 1:08 PM, Hans Hübner <span dir="ltr"><<a href="mailto:hans.huebner@gmail.com">hans.huebner@gmail.com</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 class="Ih2E3d">On Thu, Feb 26, 2009 at 22:01, Jim Prewett <<a href="mailto:download@hpc.unm.edu">download@hpc.unm.edu</a>> wrote:<br>
<br>
> I'm not quite sure what I'm after except that the buzzword seems to be<br>
> "COMET".<br>
</div></blockquote><div>... <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The cleanest way to implement a high performance I/O multiplexing<br>
framework that could be used by Hunchentoot would be by implementing<br>
multiplexed socket streams using coroutines.  Obviously, that would<br>
require a coroutine library, and I am not aware of such a thing.<br>
</blockquote><div><br>Don't you think that having separate thread handling comet would be simpler? I/O multiplexing to the clients with some sort of message queueing API for requests from the app engine would be sufficient to make it work? The only obstacle for multiplexed I/O is lack of portable non-blocking I/O library.<br>
<br>/S <br></div></div><br>