Reset on checkin

[tsnoam]

On certain usage patterns it might be more suitable to reset the values of the encapsulated data during checkin (When Checkout::drop() is executed) instead of during checkout.

[carllerche]

Thanks for the proposal. Could you describe the use case that requires reset on check-in? Before adding two options, I would like to evaluate whether reset on check-in should just be the only behavior.

[tsnoam]

The use case goes like this:

Thread 1:

A tight loop handling a massive stream of incoming data. The incoming data is stored on an object taken from the pool. Only a fraction of the incoming data is sent to an handler thread.

Handle Thread (1 or more):

Performs additional computation on the data. Once its done, the object is dropped (and returned to the pool).

Problem:

Resetting the object in the thread1 (i.e. during checkout) takes time and stalls the tight loop.

Suggested Solution:

Reset the object in the handler thread (i.e. during checkin).

[carllerche]

reset logic could also be handled outside of the crate... I wonder if pool should get rid of the Reset trait all together. wdyt?

[tsnoam]

Actually, I find the Reset logic as a really important feature of this library. It saves a lot of boilerplate code and more importantly avoids "accidents" where the developer forgets to explicitly call reset before a Checkout object is dropped.