On Wed, Jan 04, 2017 at 12:11:18AM +0000, Bryan O'Donoghue wrote:
This patch adds a generic mechanism for handling timeouts of asynchronous operations to operation.c. After doing a gb_operation_request_send() it schedules a delayed worker. When the delayed worker's timer expires the worker runs and does a gb_operation_cancel(). A gb_operation_cancel() operation will result in the operation completion callback being called with -ETIMEDOUT as the result code. If an operation completion has already taken place then the gb_operation_cancel() has no effect. This patch means that each driver doing asynchronous operations doesn't have to have its own special timeout mechanisms, it just waits for operation.c to provide it with the appropriate status code for a given operation.
So I finally found some time to dig into this. I've had some doubts about using delayed work this way since it was first suggested, even if this would still be an improvement over the custom timeout implementation in loopback of course.
The idea all along was to generalise the timeout handling in core, but this had to be pushed out for v2 due to too many other things requiring attention.
Expiring timers is more expensive than cancelling them, something which would be the common case. By throwing in a workqueue in the mix, this penalty for every (async) operation becomes even more costly.
I've implemented generic timeout support in core using just a per-operation timer instead. This simplifies the synchronous operation handling somewhat, but specifically provides an efficient timeout mechanism for driver to use for asynchronous operations as well.
The rest of your series can be rebased on top with minimal effort.
Thanks, Johan