Alexander Vershilov

@teh unfortunately we didn't move much in this direction. We had a discussion with @nh2 about the problem and solution. If I recall correctly large timing was due to TCP...

This strace looking like dumping logs to `stdout` (fd=2). I don't think it looks very nice, as seems one write is one as a multiple poll>>write calls, but it seems...

Yeah as I said in https://github.com/haskell-distributed/distributed-process/issues/206#issuecomment-277556496, we have solved similar issue for us by using TCP_NODELAY (and exposing that option in n-t-tcp API). But using TCP_NODELAY is having a latency...

Here is a summary https://github.com/haskell-distributed/distributed-process/issues/206#issuecomment-277556496 discussion itself had happened few years ago during ZuriHac in person.

@hyperthunk for the flush the idea was to introduce a new method for connection and allow a user to `flush` explicitly. Wrt tcp-nodelay it's up to the user whether to...

There is https://github.com/tweag/distributed-closure project that could be used instead of distributed static. And branches like https://github.com/haskell-distributed/distributed-process/compare/master...tweag:static-pointers-qn however not all the code was moved to distributed-closure, so there were no example...

On the other hand taking NC away from local communication removes a number of possible errors with NC lock or bottoms in values that are sent.

Mine? If NC is not used in local communication then unsafe send of message that will evaluate to error will not break NC.

Agree.

Addressed by https://github.com/haskell-distributed/distributed-process/pull/279