You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
inUse always gets decremented, regardless of if this function has been called multiple times for the same resource. Here is a demonstration of the issue:
#!/usr/bin/env stack
-- stack script --resolver lts-11.4 --package resource-pool --package stmimportControl.Concurrent.STMimportControl.Concurrent.STM.TVarimportControl.MonadimportData.Poolmain::IO()
main =do
counter <- newTVarIO 0let acquire =do
k <- atomically $do
k <- readTVar counter
writeTVar counter (k +1)
return k
putStrLn$"acquire "++show k
return k
release k =putStrLn$"release "++show k
pool <- createPool acquire release 1601
(k, localPool) <- takeResource pool
destroyResource pool localPool k
destroyResource pool localPool k
void $ takeResource pool
void $ takeResource pool
putStrLn"Bug: acquired two resources despite the pool having a limit of 1. Next resource acquire will block."
void $ takeResource pool
Output:
acquire 0
release 0
release 0
acquire 1
acquire 2
Bug: acquired two resources despite the pool having a limit of 1. Next resource acquire will block.
The text was updated successfully, but these errors were encountered:
Isn't the only way to solve this by giving LocalPools a unique id and having Pool store a Map of ids that have already been decremented?
Actually... I think that wouldn't work. The fact that no one else has chimed in makes me wonder if the burden is on the user of the library here and this isn't a pattern Pool aims at preventing. That seems wrong to me though.
The definition of
destroyResource
is:inUse
always gets decremented, regardless of if this function has been called multiple times for the same resource. Here is a demonstration of the issue:Output:
The text was updated successfully, but these errors were encountered: