This could indeed be a reason for the observed behavior. I've pushed a fix that uses a vibe.utils.hashmap.HashMap together with a manual memory allocator to fix this.

Cool. In the mean time I thought of a work-around that involved basically pulling the event I was using to trigger fibers to wake "up a level" so it is shared by all of the fibers in a room (i.e. "channel" or similar). This works great for broadcasts but of course needlessly wakes up fibers when the server only needs to send to a single client. Not currently a huge deal in my application (as those fibers fairly quickly just check their TCPConnections and send queues and go back to sleep), but not totally ideal.

The upside though is that it pretty much confirmed that was indeed the issue, as the crashes went completely away when I changed it.

Great to hear that you've put a fix in, as it was a rather difficult issue for me to track down (across two operating systems and GC implementations). Now I just need to decide if I should stick with the current solution that appears to be pretty robust or go back to the slightly more efficient per-fiber event one... hmm :)

Yeah, I want to get the libev driver to a complete and stable state at some point to hopefully get better performance than with the libevent driver, but I'm simply missing the time for that (the priority is very low, as it is basically only a performance improvement).

No rush from me, my application isn't particularly performance sensitive. I was just trying different drivers to try and work around potential issues :)

I'll implement the Win32TCPConnection.peerAddress property later today.

Great, I'll give that a try on Windows then as well. That said, the production home of my application is now on Linux, so while I do develop primarily on Windows, it's probably best for me to stick with libevent in both places to avoid as much dev/production divergence as possible :)

Another possibility would now be to use vibe.core.concurrency to send and receive messages and then start two tasks for each connection, one for reading and one for writing

That's an interesting possibility, and it sounds similar to the system that I had before I switched to vibe in the first place (i.e. some minimal event collection threads and signalling via mailboxes; i.e. one that was sitting on select, another for HTTP, etc). Might consider that in the future, but as I mentioned, I have no real need for true multithreading/parallelism currently, so introducing additional threads may just complicate things.

But to just get it working quickly, hopefully the ManualEvent fix was the right one for this issue...

Indeed, I'll give it a try and then make the call on whether to use the fixed version or my current workaround :)

Thanks for the quick response and fixes!