TypeError: kills[kid] is not a function

[felixSchl]

I am experiencing this issue in the "debounce" test case for purescript-redux-saga (https://github.com/felixSchl/purescript-redux-saga/blob/master/test/Main.purs#L291-L316).

I have done a bit of digging and found that runPars kill function returns an object, instead of a function. Somewhere the output of that gets assigned to an index in kills (I'll have to dig again to find where that happened when I get the chance, maybe later today). But the cancel function expects all entries in kill to be functions.

I've managed to "fix" the problem (that is: not have it crash, not sure if correct), by doing this:

function recKill(kills) {
  for (var kid in kills) {
    if (kills.hasOwnProperty(kid)) {
      if (typeof kills[kid] === 'function') {
        kills[kid]();
      } else {
        recKill(kills[kid]);
      }
    }
  }
}

I am sure that "fix" is incorrect so I won't bother with a PR for now.
To see this error occur, you can clone purescript-redux-saga and run pulp test.

Edit: For completeness sake, here is a stack trace:

/Users/felix/projects/purescript-redux-saga/output/Control.Monad.Aff/foreign.js:504
              throw util.fromLeft(fail);
              ^

TypeError: kills[kid] is not a function
    at cancel (/Users/felix/projects/purescript-redux-saga/output/Control.Monad.Aff/foreign.js:947:21)
    at /Users/felix/projects/purescript-redux-saga/output/Control.Monad.Aff/foreign.js:973:18
    at runAsync (/Users/felix/projects/purescript-redux-saga/output/Control.Monad.Aff/foreign.js:98:20)
    at run (/Users/felix/projects/purescript-redux-saga/output/Control.Monad.Aff/foreign.js:324:22)
    at /Users/felix/projects/purescript-redux-saga/output/Control.Monad.Aff/foreign.js:576:13
    at kill (/Users/felix/projects/purescript-redux-saga/output/Control.Monad.Aff/foreign.js:189:15)
    at /Users/felix/projects/purescript-redux-saga/output/Control.Monad.Aff/foreign.js:195:15
    at runAsync (/Users/felix/projects/purescript-redux-saga/output/Control.Monad.Aff/foreign.js:98:20)
    at run (/Users/felix/projects/purescript-redux-saga/output/Control.Monad.Aff/foreign.js:324:22)
    at Object.run (/Users/felix/projects/purescript-redux-saga/output/Control.Monad.Aff/foreign.js:621:13)

[natefaubion]

I think that the entries in kills are always nested string maps (as a result of calling kill on a section of a tree), so I think it's fine to just do a nested for-in loop. We are obviously missing a test of this case (killing a ParAff that's in the process of killing a portion of it's own tree).

[natefaubion]

This test is difficult to write because the it results in uncaught exceptions, which are rethrown in a fresh stack. We would need a way to observe these uncaught exceptions. @jdegoes is working this into his IO library for Scala, and we should probably do something similar.

[natefaubion]

I'm not suggesting you should do that, just noting that if someone were to try and write this test, they would have a hard time without library support. 😛

[natefaubion]

Hmmm... If an alt branch is being killed, and then we kill the entire fiber, should we wait until the pending kill is completed? That is, if we are killing a branch of an alt, that's like saying it's invincible. Or should we cancel the join attempt? I guess this applies generally, and we should be consistent either way.

Currently, if a fiber is waiting on a kill (which is a kind of join), and we kill that fiber, it will only cancel the join attempt. That is, it isn't possible to kill a kill, but you can kill the observation of a kill, such that when the kill does complete, it may result in an uncaught exception. But maybe we should be treating a kill as invincible? That is if you kill a fiber waiting on a kill, it must wait for the inner kill to complete for proceeding with running it's own finalizers. @jdegoes do you have any thoughts?

[natefaubion]

I think for the purposes of sequential/ParAff, it makes sense to think of it like a new supervision context, so we should be waiting for all branches to be finalized. For arbitrary fork/kill, the user has control of that behavior, but not in the case of ParAff since it is completely managed by the runtime.

[jdegoes]

@natefaubion

I believe that if you kill a fiber waiting on a kill, then it must wait until the inner kill completes, then proceed with the outer kill, and finally resume the initial interrupt.

These semantics come up several other places. For example, if you race a and b, and a wins, then b must be terminated, and race may not return until b terminates, even though the race outcome has already been decided and the value is already available.

Similarly, if you do a and b in parallel, but b dies, then joins on the parent parallel computation will resume only when a has been shut down and all finalizers have been run.

These semantics, which can be described as always waiting for all other computations to terminate cleanly, recursively, are at least pervasively consistent, and minimize leaks because you have strong guarantees that when computations resume, any failures or interruptions which contributed to those resumptions have been entirely resolved, so you are free to acquire new fibers / resources.

In some use cases, it's these guarantees are too strong, but I found you can always achieve other semantics with use of an MVar / AVar and fork.

[natefaubion]

@jdegoes Yeah, I think we basically agree. The examples you listed all apply to ParAff where the runtime manages fibers. In that case the only thing you really can do is wait for finalizers, and is what is implemented. I don't think it's necessary to do this for unsupervised forks in general though. In the ParAff and supervised cases there's a clear hierarchy/scope. But otherwise there's no reason for an arbitrary fiber to have to wait for another arbitrary fiber to finish finalizing.

The simplest semantics for kill (absent any scope) is to interrupt the currently pending asynchronous action and then run the fiber's finalizers. If you interrupt a normal joinFiber action, you would not expect it to keep waiting. Likewise, with a killFiber (which is just a special case of joinFiber) I don't think you would expect it to necessarily wait. If you wanted it to wait, you would do invincible (killFiber err fiber). I don't think it's necessary to bake invincible into killFiber directly.

[jdegoes]

I agree, I think you should be able to interrupt killFiber without issue, unless of course they've made it invincible.

Relatedly, I was thinking a hypothetical supervise++ combinator could offer the following signature:

supervise :: forall a. (Error -> IO Unit) -> (forall b. IO b -> IO b) -> IO a -> IO a

i.e. when you supervise an action, you can control (a) what happens to uncaught errors, and (b) transform the children forked by the IO a.

In particular, this allows you to, with some difficulty, recover the ability to automatically kill forked fibers when the parent action is terminated, via adding a bracket finalizer (you just need an MVar, and of course a helper combinator could be provided).

The problem with this signature is that it imposes much more overhead on killing lots of forked fibers, so I'm not sure it's a net gain. I'll keep thinking of alternatives.

[natefaubion]

@jdegoes I will make another issue about potentially expanding the supervisor API.