{"push_id":947891514,"size":1,"distinct_size":1,"ref":"refs/heads/stw","head":"903aae172c8a399172b0e6c62246a90b90f5c31e","before":"03f8943231bc6a45b0bc8c6eff7fcb10473b81d4","commits":[{"sha":"903aae172c8a399172b0e6c62246a90b90f5c31e","author":{"email":"1ea48a69f09ca4fa2c0ea576825eb76dcaab3f18@gmail.com","name":"Brian Shirai"},"message":"Introduce SleepPhase.\n\nThread semantics are ad hoc in Ruby so we make a best effort to mimic them\nwhere possible. The behavior of process exit when one or more threads are\nsuspended in a sleep state is not well-defined. We assume that no sleeping\nthread should block the process from exiting. We introduce a specific \"sleep\nphase\" as one state a thread may be in. We then ignore sleeping threads when\nexecuting a process exit.\n\nUnfortunately, this is more complex than it appears on its face. While\nexecuting a process exit, we are essentially racing any sleeping threads that\nmay wake up and attempt to access resources that are being destroyed (something\nlike one of those scenes from Inception with the buildings crumbling around the\nparticipants). We cannot waking thread proceed once process exit has started,\nso we permanently lock a mutex that every waking thread must acquire before\nprogressing.\n\nUltimately, these lock resources will need to be in the program's data segment,\nso they are static memory, not dynamically allocated, as they are now.","distinct":true,"url":"https://api.github.com/repos/rubinius/rubinius/commits/903aae172c8a399172b0e6c62246a90b90f5c31e"}]}