Actually I can live without asynchronous I/O (smth like posix aio_* functions). Just nonblocking read and select/poll would be enough. I have some experience with threads and believe that they just are not worth the throuble in most cases. I find the twisted python's approach (with reactor and deferreds) much more elegant. So I wanted to implement smth similar in arc but it seems I can't at least in the obvious way.
Yes, thanks, it must work. But it means that you need to have exactly N suspended threads when you're waiting for data from N sockets. Thread pool helps a lot but in worst case you will still need exactly N threads.
Thread management is done automatically for you by the underlying mzscheme. A bit more of research seems to suggest that mzscheme can actually handle blocking I/O even if it uses green threads, and it can also have OS threads if compiled with support for it.
MzScheme does not use OS threads. A long time ago it did, but it is pretty hard to make it work on Windows, OS X and Linux at the same time. Also context switching becomes cheaper without OS threads.
If you have found anything on OS threads in "Inside MzScheme" it must be in the section on how to embed MzScheme into a C program (with its own thread).
Oh, is that rather usual that scheme implementation uses green threads? If so, maybe I really shouldn't worry about it. I was concerned only because I thought it was expensive to have one system thread per connection.
