Closed zeenix closed 1 year ago
One idea from @sdroege is that we simply always use non-blocking socket and use epoll for all blocking calls. if we go this route and we continue to support the non-blocking connection API, we'll need a way to differentiate the case of non-blocking vs. blocking connection. In case of former, we'll want to forward the WouldBlock returns from the socket to the user.
mentioned in commit 083d77b7735cf583e92ead86b330a39a10d92dfc
mentioned in commit 0d69b88f84f28bc6a52b6c979a24327073c1ac68
mentioned in commit 92f2f46242e597952576aba81680dee3ee2d0cc0
mentioned in commit 97f36d3da8be074c0f4c350b30838ab4530df5be
Currently if one thread is reading from a Connection and another writes to it, it'll end up in a deadlock (at least until the a message is received on the socket). We should try and ensure that doesn't happen.
It'll be very tricky though. We'll need some kind of channel that we can poll together with the underlying socket. The sender thread can then use the channel to wake-up the receive call and get the lock on the socket.