Seems like we can safely refactor timeout-divergence into separate risk. Say we have some facility to run the expression evaluation within the provided timeout, so we can always apply time bound externally (e.g. on the client side). By the way, using Stream.resource/3/try-rescue in WithTimeout looks safe, since the only thing performed on the resource (Task.Supervisor) is spawning task to await.
Good insights. For example, the one on a data copying concern (addressed in DBConnection.Holder). Again as a sidenote — Stream.resource/3/try-rescue does everything in-place, so no cost on copy messages.
That is tough! Agree, an existing library for such case would be Elixir (Erlang) itself.
To sum up on fault tolerance:
- While
ResourceusesStream.resource/3under the hood, it could be seen as a solution for the same class of problems, one can approach withStream.resource/3(up to resource streaming necessity); - timeout-divergence could be addressed on demand (applying time bounds on the resource usage).
And yes, Resource is not the way you should approach highly specific resource management domains (e.g. HTTP connection pools). Now I see, that Resource’s name could be slightly misleading in such a context. Its focus is mainly not on the resource object itself (there could be no “object” at all), but on the “bracketing-the-usage” ceremony (do this on acquire, do that on release).
But I’ll try to dig more on Stream.resource/3 backend alternative.
