Please sign in to comment.
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Thread semantics are ad hoc in Ruby so we make a best effort to mimic them where possible. The behavior of process exit when one or more threads are suspended in a sleep state is not well-defined. We assume that no sleeping thread should block the process from exiting. We introduce a specific "sleep phase" as one state a thread may be in. We then ignore sleeping threads when executing a process exit. Unfortunately, this is more complex than it appears on its face. While executing a process exit, we are essentially racing any sleeping threads that may wake up and attempt to access resources that are being destroyed (something like one of those scenes from Inception with the buildings crumbling around the participants). We cannot waking thread proceed once process exit has started, so we permanently lock a mutex that every waking thread must acquire before progressing. Ultimately, these lock resources will need to be in the program's data segment, so they are static memory, not dynamically allocated, as they are now.
- Loading branch information
Showing with 56 additions and 7 deletions.