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
mkDebounce internally forks a thread, but never kills it. To reproduce, run the following with +RTS -s -RTS and observe memory usage.
importControl.DebounceimportControl.Monadmain::IO()
main = forM_ [(0::Int) ..100000] $\_ ->do
r <- mkDebounce defaultDebounceSettings
r
Output:
250,129,600 bytes allocated in the heap
417,814,184 bytes copied during GC
47,018,288 bytes maximum residency (8 sample(s))
3,325,648 bytes maximum slop
132 MiB total memory in use (0 MB lost due to fragmentation)
132MiB memory is too much for the above program.
As a possible solution, consider attaching a finalizer to the debounced action that will kill the thread. I'd be happy to prepare a patch if you agree with such a solution.
Other possibility is to use a closable channel instead of MVar. I didn't try it though.
A bit of context: fast-logger uses mkDebounce to flush logs, so each logger comes with a thread which never exits.
Thanks!
The text was updated successfully, but these errors were encountered:
I guess mkDebounce could also provide a finalizer?
Or create a function that captures its own MVar and doesn't need to fork a thread?
mkDebounce::IO()->IO (IO())
mkDebounce action =do
baton <- newMVar ()pure$do
mBaton <- tryTakeMVar baton
case mBaton ofNothing->pure()Just()->do-- handle Leading/Trailing-- and `putMVar ()` when done with action + delay
@kazu-yamamoto would this idea be an ok replacement for Control.Debounce.mkDebounce? Or do you see any issues with it? (a finally putMVar might also be needed, come to think of it)
mkDebounce
internally forks a thread, but never kills it. To reproduce, run the following with+RTS -s -RTS
and observe memory usage.Output:
132MiB memory is too much for the above program.
As a possible solution, consider attaching a finalizer to the debounced action that will kill the thread. I'd be happy to prepare a patch if you agree with such a solution.
Other possibility is to use a closable channel instead of
MVar
. I didn't try it though.A bit of context: fast-logger uses
mkDebounce
to flush logs, so each logger comes with a thread which never exits.Thanks!
The text was updated successfully, but these errors were encountered: