Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exception when trying to kill fiber from its own fork code #217

Open
m-bock opened this issue Nov 7, 2023 · 4 comments
Open

Exception when trying to kill fiber from its own fork code #217

m-bock opened this issue Nov 7, 2023 · 4 comments

Comments

@m-bock
Copy link

m-bock commented Nov 7, 2023

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

  1. Open complete minimal reproducible example on Try PureScript

  2. 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.

@natefaubion
Copy link
Collaborator

While I agree it shouldn't throw like that, what do you expect the result to be?

@m-bock
Copy link
Author

m-bock commented 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 killFiber throws an error like "tried to kill fiber from within itself".

@natefaubion
Copy link
Collaborator

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.

@m-bock
Copy link
Author

m-bock commented 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants