-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Rethink Pool
design
#28
Comments
the e.g.
but if they're the other order:
|
i find the "keyed" pool also a bit odd, especially the interaction with
when you julia> pool = Pool{String, Int}(3);
julia> pool.keyedvalues # <- no stores
Dict{String, Vector{Int64}}()
julia> acquire(() -> 0, pool, "a");
julia> pool.keyedvalues # <- now there is an "a" store
Dict{String, Vector{Int64}} with 1 entry:
"a" => [] when you julia> pool = Pool{String, Int}(3);
julia> x1 = acquire(() -> 1, pool, "a");
julia> pool.cur # <- 1 permit in use
1
julia> release(pool, x1); # <- error to release without providing a key
ERROR: ArgumentError: invalid key `nothing` provided for pool key type String
Stacktrace:
...
julia> pool.cur # <- the permit is still in use
1
julia> release(pool, :z, x1); # <- error to release while providing a key of the wrong _type_
ERROR: ArgumentError: invalid key `z` provided for pool key type String
Stacktrace:
...
julia> pool.cur # <- the permit is still in use
1
julia> release(pool, "z"); # <- fine to release while providing a unknown key
julia> pool.cur # <-- the permit was released
0 why do we require a key which we're not going to use, but require it to have the right type but not a known value? if you want to release the permit and return the object to the store for re-use, then it makes sense that you need to provide a key... but we don't allow returning things to a new store (you can only make stores at julia> pool = Pool{String, Int}(3);
julia> x1 = acquire(() -> 1, pool, "a");
julia> release(pool, :z, x1) # <- error to release / return object while providing a key of the wrong _type_
ERROR: ArgumentError: invalid key `z` provided for pool key type String
Stacktrace:
...
julia> pool.cur # <- the permit is still in use
1
julia> release(pool, "z", x1) # <- error to release /return object while providing a unknown key
ERROR: KeyError: key "z" not found
Stacktrace:
...
julia> pool.cur # <-- but the permit was released (despite the error)
0 |
i noticed that
Pool
is currently providing two things, which i think it is confusing to combine (at least in the way they're currently combined):Semaphore
to limit the maximum number of objects in use at a timeBut note that the limit is on the "permits" (the number of objects in use), not on the "store" (the number of object available for re-use), on which there is no limit, e.g.
I worry this could lead to a potential memory leak for users who do not realise that the "store" can grow arbitrarily in size and never be cleaned up.
I wonder if the size of the "store" should also be limited (for example,
forcenew
could force an eviction either always or if the collection is at capacity)The text was updated successfully, but these errors were encountered: