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
{{ message }}
Repository navigation
Exception when trying to kill fiber from its own fork code #217
Describe the bug
The excpetion "TypeError: step is not a function" is thrown when a fiber is killed from its own fork code:
main :: Effect Unit
main = launchAff_ do
ref <- liftEffect $ Ref.new Nothing
fib <- forkAff do
delay (Milliseconds 500.0)
maybeFib <- liftEffect $ Ref.read ref
case maybeFib of
Just fib -> do
killFiber (Aff.error "killed") fib
Nothing -> do
pure unit
pure unit
liftEffect $ Ref.write (Just fib) ref
delay (Milliseconds 1000.0)
To Reproduce
Open complete minimal reproducible example on Try PureScript
Open the dev console, it shows the Error:
foreign.js:521 Uncaught TypeError: step is not a function
at foreign.js:590:59
at foreign.js:10:16
at foreign.js:10:20
at runAsync (foreign.js:96:20)
at run (foreign.js:331:22)
at foreign.js:346:19
at drain (foreign.js:118:9)
at Object.enqueue (foreign.js:139:11)
at foreign.js:337:27
Expected behavior
There should be no error in the console.
Additional context
Happens in node and in the browser.
I would expect that the killing behaves exactly how it would if the fiber was killed from outside. Otherwise, in case the library does not want to support this, I'd expect that killFiber throws an error like "tried to kill fiber from within itself".
Your example demonstrates the exception, but did this arise naturally in your code? Was a self-kill an intentional design consideration, or was this manufactured to see what would happen? Generally one wants to create a DAG of fibers, as a cycle can't ever successfully resolve. That is, joinFiber f = never when f is the current fiber.
It came up in a real use case, but rather as a convenience than as a necessity: Inside a function two fibers where spawned and there was a cleanup function to kill the fibers and do some other things. This cleanup function was called at several places, also in error handlers at the top level of each fiber. The solution was simply to introduce more granular cleanup functionality.
Activity
natefaubion commentedon Nov 7, 2023
While I agree it shouldn't throw like that, what do you expect the result to be?
m-bock commentedon Nov 7, 2023
I would expect that the killing behaves exactly how it would if the fiber was killed from outside. Otherwise, in case the library does not want to support this, I'd expect that
killFiberthrows an error like "tried to kill fiber from within itself".natefaubion commentedon Nov 7, 2023
Your example demonstrates the exception, but did this arise naturally in your code? Was a self-kill an intentional design consideration, or was this manufactured to see what would happen? Generally one wants to create a DAG of fibers, as a cycle can't ever successfully resolve. That is,
joinFiber f = neverwhenfis the current fiber.m-bock commentedon Nov 8, 2023
It came up in a real use case, but rather as a convenience than as a necessity: Inside a function two fibers where spawned and there was a cleanup function to kill the fibers and do some other things. This cleanup function was called at several places, also in error handlers at the top level of each fiber. The solution was simply to introduce more granular cleanup functionality.