Ringbuf: add timeout API

[RonFed]

Following #1111, I think it is possible to add a SetTimeout or ReadTimeout API to rigbuf
I saw there was some discussion about this in the past here #523 (comment)
The reason behind adding the timeout option is to avoid re-setting the deadline before each read, which is the scenario today
In case I want to call Read() and I'm willing for it to block for max of 5 seconds for example, I'll have to re-do the SetDeadline(time.now().add...)
With a timeout API it will save this. In addition, the epoll syscall takes a timeout argument as mentioned in the above mentioned discussion
If you agree, I'll be happy to add this (might need to define how timeout is working when deadline is also possible and when each option is taken)

[lmb]

In case I want to call Read() and I'm willing for it to block for max of 5 seconds for example, I'll have to re-do the SetDeadline(time.now().add...) With a timeout API it will save this.

Why is this a problem? Performance? Ease of reading the code? Something else?

In addition, the epoll syscall takes a timeout argument as mentioned in the above mentioned discussion

Why is this an argument in favour of adding timeout? I still believe that the correct semantics are that deadline or timeout indicate how long you are willing to wait for Read to return, not how long epoll will block. So you won't be able to pass the timeout directly to epoll in any case.

[RonFed]

Why is this a problem? Performance? Ease of reading the code? Something else?

I think both performance and code readability will improve from adding the timeout API.

Why is this an argument in favour of adding timeout? I still believe that the correct semantics are that deadline or timeout indicate how long you are willing to wait for Read to return, not how long epoll will block. So you won't be able to pass the timeout directly to epoll in any case.

I think the current approach is doing extra work converting the deadline to timeout in the func (p *Poller) Wait - There is the line msec := time.Until(deadline).Milliseconds(). Hence, if I'm interested in timeout for calling Read - there is a conversion I need to do before each call to Read using SetDeadline(time.now().add...) and in addition the poller will basically undo this conversion - so all these conversions looks like redundant code to me (in the case of timeout as specified).

[lmb]

Can you explain how to implement Read with the current semantics without doing the conversion? I don't know how that would work to be honest.

[RonFed]

With the current deadline semantics, there is no way to avoid the conversion in msec := time.Until(deadline).Milliseconds().
However, if we add a timeout option for the user this conversion can be saved - which means the func (p *Poller) Wait will have to change a bit. Maybe adding a timeout field to Poller and checking if it is set in the Wait function?

[lmb]

Okay, my stance is still that the current semantics are correct. You're arguing that doing the conversion is "more work", but you've not quantified how much more work it is. Really, the only reason I'd consider changing this is if you'd ran into time.Now in a production profile. My gut feeling is that the work really is miniscule compared to doing the epoll syscall.