cleanup code to remove race conditions

[whyrusleeping]

This is a moderate rewrite of the bindings to clean up some race conditions, and remove unnecessary async stuff. It also has roughly double the throughput as before.

[jbenet]

I don't recall why this was all there. thought the C++ lib was not threadsafe-- is it?

think should stress it hard. probably could use https://github.com/jbenet/go-stream-muxer/ to stress it.

[jbenet]

this repo doesnt run tests and thus i don't feel safe merging this. maybe add travis ci testing with some stress stuff first?

[jbenet]

• enable it on travis
• add .travis.yml
• add stress test.

[jbenet]

I find it very concerning that:

• in go 1.4 the tests take ~1min to run.
• in go 1.5 the tests timeout after 10min

See:

• https://travis-ci.org/jbenet/go-udtwrapper/builds/81741919
• https://travis-ci.org/jbenet/go-udtwrapper/builds/81741924

either there's an issue with 1.5, or there's possibly a deadlock.

[jbenet]

Maybe it was travis? /still concerned

[jbenet]

seems to have deadlocked on travis again. hit 10m timeout in both 1.4 and 1.5

[jbenet]

And again.

[whyrusleeping]

@jbenet strange, i did 'go test -count 50' and the first 8 or so passed normally, but the 9th errored with an EOF.

Wasnt able to reproduce a hang though... (but I should mention that the stress test eats my machines resources like no other)

[whyrusleeping]

so, completely unable to repro a hang locally, but I can repro a random EOF on the reads.

the EOF is caused by an EINVSOCK being returned, looking what returns that from the code tells me that the socket i'm trying to read from either does not exist, or has been closed (same error message for both, aint that great?)

My naive guess (still reading through the c++ code) is that somehow the 'close' packet gets received by the reader before some of the final data, causing the EINVSOCK to be returned before my reads actually finish

[whyrusleeping]

also:

thought the C++ lib was not threadsafe-- is it?

He says its completely threadsafe here: http://udt.sourceforge.net/udt4/doc/t-intro.htm
I'm hoping hes right.

[whyrusleeping]

I'm going to have to mark my suspicions about the close confirmed. I made the reader send a small message back to the writer once its read the expected amount and I no longer see that error.

[whyrusleeping]

I lowered the number of test connections. It was using over 3GB of ram on my machine, and when i applied additional stress to the system (running other traffic over localhost and stressing my cpu a bit) the amount of ram used went up even more.

I assume that travis doesnt give us that much ram to work with and we may have sunk into swapdeath causing the hangs we saw.

[whyrusleeping]

@jbenet ping!