I would like the ability to have the same thread block on a socket and block on cross-thread messages at the same time. Currently, the receive function in std.concurrency and the receive function in std.socket are not tied together at all, so I don't think this is possible without modification to the standard library. Thanks, Phil Deets Disclaimer: I work for Microsoft, but I am not representing them in any way by this post.
Heh, the coveted One True Event Loop... unless you can get select() and whatever synchronization primitives various platforms use to play together, this isn't going to happen. Since you've decided to mention that you work for Microsoft, let's look at Windows specifically - I don't see a WSASelectAndWaitForMultipleObjects function anywhere. You'll just need to put your event loops in different threads and make one pass its events to whichever you pick as your "main" one (or alternatively, use a lock on the global state and process events in the same thread). If anyone has any realistic ideas, feel free to reopen.
I'm not an expert in Windows sockets, but I think this might actually be doable in Windows. The select function does synchronous IO; so it isn't possible with that, but I think if you use other functions (WSAEventSelect looks promising), you can associate the wait with a handle that you can use with WaitForMultipleObjects. I won't reopen the bug though as this isn't very important to me anymore. As for the disclaimer, I was newer to the job then and was perhaps a bit overly cautious about how I handled Internet communications.
Good point with WSAEventSelect. Still, it'd need some major refactoring, special-casing Windows, and we still don't know how to do this on POSIX (getting pthreads and select to work together, I guess). Web search results on the topic aren't very inspiring: http://www.google.com/search?q=pthreads+select Creating two threads with each processing its type of events still seems the way to go.