GitLab

extract buffer pool (and simplify interface)

don't hold the lock when closing

In libp2p, Close is assumed to be threadsafe and we'd like to interrupt
in-progress reads/writes.

As a matter of fact, we're lucky this hasn't caused close to hang. If we had
tried to close the reader before closing the writer, we would have blocked on a
concurrent read call.

Part of ipfs/go-ipfs#2823

Update Travis CI to use standard test script.

This also: removes old go versions; disables sudo; turns off email
notifications and caches gx directories; disables "Non-standard
signatures" check in "go vet" (otherwise "go vet" will complain about
the signature for ReadFrom and WriteTo methods for Chan).

Fix some erroneous pointer types

make ByteSlicePool a *Pool, not a Pool.

This way, copying it won't copy the underlying pool.

Also, initialize it immediately instead of in an `init` function to ensure that
it's fully initialized immediately.

fix repo

This has moved to libp2p

Make mpool *much* faster

Per the documentation, this example *isn't* guaranteed to work (and, in
practice, it fails occasionally).

1. They're small.
2. We can avoid the lock (major speedup).
3. Better memory locality.
4. Much simpler.

fix erroneous member assignment bug from d5bbf59d

fix for bounds errors on 32 bit systems

limited + tool

reduce maximal size of one message to 8mb

found two panics with go-fuzz

remove the size checks and you get out of bounds panics