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

Implement trap #17

Open
propensive opened this issue Dec 1, 2024 · 2 comments
Open

Implement trap #17

propensive opened this issue Dec 1, 2024 · 2 comments
Assignees
Labels
api Relates to the API design core Describes core required functionality enhancement An improvement to existing functionality

Comments

@propensive
Copy link
Owner

With structured concurrency, a child thread may throw an exception which, by default, will terminate execution of the thread, but will be lost. A method should be provided to ensure that exceptions are never "lost" in this way.

Whatever method is used for defining the exception handling, it should be hierarchical, and conform to the concurrent structure. In particular, stack safety should be maintained. It should not be possible to smuggle a resource outside of its bounded stack using an exception. If an exception is not handled in one thread then it should be handled by that thread's parent.

At the top level, a Supervisor must handle the exception one way or another, but this should be determined by a contextual value.

@propensive propensive added enhancement An improvement to existing functionality api Relates to the API design core Describes core required functionality labels Dec 1, 2024
@propensive propensive self-assigned this Dec 1, 2024
@github-project-automation github-project-automation bot moved this to Todo in Soundness Dec 1, 2024
@propensive propensive changed the title Investigate possibilities for siphoning exceptions from child threads Implement trap Dec 2, 2024
@propensive
Copy link
Owner Author

A typical usage would be:

async:
  val x = 1

  trap/*(using Monitor)*/:
    case error: Exception => Out.println(error)
  .within: // using monitor =>
    val y = 2
    async(calc(x, y))

trap will take a partial function, with return type Unit. It will capture the Monitor from the surrounding scope (so it will only be usable in an async context), and supply a new Monitor to the within body. If that body throws an exception, it will be matched against the partial function, or passed up to the parent Monitor. At the top of the chain, the supervisor will handle the uncaught exception according to a contextual value.

@propensive
Copy link
Owner Author

trap is implemented, but it's not clear yet whether it works reliably.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api Relates to the API design core Describes core required functionality enhancement An improvement to existing functionality
Projects
Status: Todo
Development

No branches or pull requests

1 participant