RejectedSoftware Forums

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!

On Wed, 01 May 2013 17:11:19 GMT, punkUser wrote:

Hmm so I recently tried updating to .7.15 and ran into some issues that might be related to this fix, even in the case where I'm not deleting events (i.e. my workaround implementation).

Specifically, I'm seeing access violations and crashes inside "rawYield" and similar functions (and some of them seem related to HashMap, which I believe was the change that is made). Similar to before, if I force GC.collect() frequently it seems to be easy to reproduce, but I haven't had time to hunt more into what is going on.

I can maybe try to come up with a small-ish repro in the next week or two, but since I'm fairly busy in actually finishing this project I've had to revert to .7.14 in the mean time, which works fine if I avoid freeing manual events. If you have any ideas on what I can try in the mean time in .7.15, please let me know.

Thanks!

A repro case (doesn't necessarily have to be reduced) would be great. But apart from that I'll keep it in mind to do some stress tests with explicit GC.collect() calls.

Okay, I think I got it. HashMap missed to call GC.addRange() for its table. Since the table contains a bool[Task] map, this could cause access violations, as the map would be collected immediately by the first GC run.

https://github.com/rejectedsoftware/vibe.d/commit/97d87ccdf3c7fdd9aef29032e02c2e26fa60e1ef

Ah, sweet, I will definitely check that out. That sounds consistent with what I was seeing (i.e. dies immediately even without any events being killed). Sorry for the lack of repro in the mean time, the issue was mostly that I didn't have a good way to emulate the client side (i.e. the game) of it in a test case, not so much that it was hard to pare down the server part.

On Sun, 12 May 2013 03:39:23 GMT, punkUser wrote:

Hmm just updated to the latest snapshot and now ".acquire/release" won't compile on my ManualEvents... any ideas? Is there now a better way to implement the "wait on multiple objects" for broadcast functionality I'm currently doing with acquire/rawYield?

I made this change that removes the explicit ownership handling after some conversation with Vladimir Panteleev. A project that I'm working on finally convinced me that the explicit ownership model can get really involved up to a point where the advantages (mostly better avoidance of concurrecy bugs and the possibility to do low level trickery) start to lose all of their attraction. It also is consistent with how ordinary synchronous I/O works. Just "wait for multiple objects" now needs a different solution than using rawYield (which is a good thing, but this is still unresolved).

But together with this change it has become possible to read and write in parallel from different tasks. So a broadcasting facility could now be implemented similar to this (untested), using the new message passing facilities:

import vibe.core.concurrency;
import vibe.core.core;
import vibe.core.net;

struct Message { /*...*/ }
Message readMessage(InputStream str) { /*...*/ }

struct ConnInfo { Task readTask, writeTask; }
ConnInfo[] conns;

void onConnection(TCPConnection conn)
{
    ConnInfo ci;
    ci.readTask = runTask({
        while (!conn.empty) {
            auto msg = readMessage(conn);
            foreach (c; conns)
                if (c.readTask !is Task.getThis())
                    c.writeTask.send(msg);
        }
        ci.writeTask.interrupt(); // TODO: nicer shutdown
    });
    ci.writeTask = runTask({
        while (conn.connected) {
            receive((Message msg) {
                msg.writeOut(conn);
            });
        }
    });
    conns ~= ci;
}

My apologies for the breakage, it was unfortunately not avoidable in this case - but for the better, I think.