> I would like to suggest again my idea of doing it in Connection instead,
> with new methods (e.g. locked_send and locked_recv). Especially given
> it can be useful in user code to have a thread-safe Connection (I'm in
> this situation currently).

I intended to do this initially, but then it turned out to be much
more intrusive than what I initially thought, and opted for a simpler
approach.

While it's probably a good idea to implement it in Connection, I don't
really like the idea of adding new distinct methods:
- this would require allocating locks for every connection, which
wouldn't be used most of the time
- since locks are implemented atop POSIX semaphores and some platforms
only support a handful of them, it could trigger some failure
- it's not really just adding locked_send() and locked_recv(): you
must implemented locked
send_bytes/send/recv_bytes/recv_bytes_into/recv: also, if we want to
implement timed and non blocking receive (which is supported by
Queue.get), it should probably be handled here

So basically, I think the right way to do it would be to define an
abstract ConcurrentConnection, or AtomicConnection which would
override Connection methods making them thread/process safe.
We'd also need exposing AtomicPipe...