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

Blocking code is not always properly handled #1543

Open
ghik opened this issue Feb 25, 2022 · 3 comments
Open

Blocking code is not always properly handled #1543

ghik opened this issue Feb 25, 2022 · 3 comments

Comments

@ghik
Copy link
Contributor

ghik commented Feb 25, 2022

Reproduction

import monix.eval.Task
import monix.execution.Scheduler

object Bug extends App {
  implicit val scheduler: Scheduler = Scheduler.forkJoin(1, 128)

  val task = Task.async[Unit](_.onSuccess(())).map { _ =>
    Task.evalAsync(println("foo")).runSyncUnsafe()
  }
  task.executeAsync.runSyncUnsafe()
}

Current behaviour

Deadlock

Expectation

No deadlock. The blocking .runSyncUnsafe() call should prompt the underlying thread pool to allocate a new thread in place of the blocked one.

Analysis

The culprit is monix.execution.internal.Trampoline.trampolineContext which overrides the parent BlockContext that is responsible for wrapping the blocking code in ForkJoinPool.managedBlock

@alexandru
Copy link
Member

Thanks for the analysis @ghik, needs to be investigated.

@ghik
Copy link
Contributor Author

ghik commented Apr 5, 2022

Hi, IMO this bug should target 3.x series - we needed to build and maintain our own version with the fix from #1544 included.

@alexandru
Copy link
Member

@ghik thanks. I merged the PR. Will plan for a new 3.x release.

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

No branches or pull requests

2 participants