Closed talex5 closed 1 year ago
I am curious to see what the version that exposes the slot looks like, to avoid all the callbacks for the lifetime management...
I am curious to see what the version that exposes the slot looks like, to avoid all the callbacks for the lifetime management...
The simplest case would be just:
type 'a t
val create : int -> 'a t
val use : 'a t -> ('a ref -> 'b) -> 'b
When using the pool you get a slot (initially empty) and it's up to you to create a new resource and store it in the slot. That would mostly force people to create their own wrappers around pool.
Alternatively, the wrapper could be passed to create
:
type 'a t
module type RESOURCE = sig
type t
val use_slot : t ref -> (t -> 'b) -> 'b
end
val create : (module RESOURCE) -> int -> 'a t
val use : 'a t -> ('a -> 'b) -> 'b
This is similar to
Lwt_pool
.It provides a similar API to @darrenldl's draft in #566, but:
Cells
queue, which should be more efficient.I removed the clear function for now. According to https://sherlocode.com/?q=Lwt_pool.clear, the only user of
Lwt_pool.clear
is Lwt's own tests!The docs note some complications regarding switches. We should probably try to make this simpler in future. e.g.
alloc
with a temporary switch: if it fails then everything is released, but if it succeeds then the resource gets adopted by the pool switch.Instead of providing
validate
,dispose
andalloc
functions, we could just expose the slot and let the user deal with it. That would give maximum flexibility.