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
I wanted to play with an API that cleans up a thread automatically when its handle goes out of scope. This would probably be an error condition (or bug) and so we'd usually want to log when this happens. The idea being to protect from leaks, while not being restricted to withAsync.
I thought I could do this myself with a weak reference and finalizer on the ThreadId from the Async, but this isn't safe since I also don't want the thread to be killed until the _asyncWait action becomes unreachable too.
I suppose that STM action would have to touch the ThreadId in some way, rather than just being readTMVar, and then the finalizer could be safely attached to the ThreadId?
The text was updated successfully, but these errors were encountered:
Firstly, if the thread is running then it won't be considered dead by the GC because the run queue is a source of roots, so this would only work for blocked threads.
If this is OK, then I guess your idea of touching the ThreadId from the _asyncWait action would be one way to do it, I can't think of a better way off hand.
I wanted to play with an API that cleans up a thread automatically when its handle goes out of scope. This would probably be an error condition (or bug) and so we'd usually want to log when this happens. The idea being to protect from leaks, while not being restricted to
withAsync
.I thought I could do this myself with a weak reference and finalizer on the
ThreadId
from theAsync
, but this isn't safe since I also don't want the thread to be killed until the_asyncWait
action becomes unreachable too.I suppose that
STM
action would have totouch
theThreadId
in some way, rather than just beingreadTMVar
, and then the finalizer could be safely attached to theThreadId
?The text was updated successfully, but these errors were encountered: