Possible unexpected blocking behavior?

[dovahcrow]

The eventfds are only read in the block* method on the sender and receiver. It seems possible that writing to these eventfd will block if they are never read, once the counter in the eventfd reaches maximum

A write(2) call adds the 8-byte integer value supplied in
its buffer to the counter. The maximum value that may be
stored in the counter is the largest unsigned 64-bit value
minus 1 (i.e., 0xfffffffffffffffe). If the addition would
cause the counter's value to exceed the maximum, then the
write(2) either blocks until a read(2) is performed on the
file descriptor, or fails with the error EAGAIN if the
file descriptor has been made nonblocking.

[diwic]

In theory I think you're right. But do you see a practical scenario where this could actually happen, or is it a theoretical issue only? Not only because of the 2^64 times you have to write without reading, but also because both sides would either use the blocking function provided, or register the fd with an event loop for all practical cases, right?

[diwic]

So, according to the benchmark we're able to send approx 10 packets per microseconds, and 2^64 / 10000000 / 86400 / 365 = 58000 years before it overflows :-) So seems like a theoretical problem to me.

That said I don't mind fixing it if you have a good solution for it? Or just write a comment that this is a problem that exists in theory.

[dovahcrow]

if both sides use an event loop, they can still not read it. But I agree that 2^64 is large enough. This question just came to my mind when learning how shmem-ipc works.