This appears to be correct. However, what asynchronous I/O do you need?
It may be possible to write some sort of semaphore-like object which would synchronize across threads, alternatively I think you can probably query the state of threads.
Also, how do you want async I/O? Do you want a callback style where a callback function is called once the I/O completes or fails? Or an async I/O which aborts if it doesn't complete within the necessary time?
Either of the above solutions is implementable using threads.
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.
