about summary refs log tree commit diff stats
path: root/073wait.cc
Commit message (Collapse)AuthorAgeFilesLines
* 3265Kartik K. Agaram2016-08-271-2/+5
| | | | | | | | | | | | | | | | | | | Ah, the reason commit 3258 broke chessboard.mu was that I forgot to migrate the implementation of 'switch' to 'wait-for-routine-to-block'. That caused these cascading effects when running chessboard.mu: a) 'read-event' from real keyboard calls 'switch' b) 'switch' waits for some other currently running routine to *complete* rather than just block c) deadlock unsurprisingly ensues This was hard to debug because I kept searching for occurrences of 'wait-for-routine' that I'd missed, and didn't realize that 'switch' too was a form of 'wait-for-routine'. No more; now it's a form of 'wait-for-routine-to-block', possibly the *only* reason to ever call that instruction outside of tests.
* 3264Kartik K. Agaram2016-08-271-0/+11
| | | | | | Turns out chessboard.mu started deadlocking in commit 3258 even though all its tests continue to pass. Not fixed yet; first make deadlock easier to diagnose.
* 3258Kartik K. Agaram2016-08-261-17/+108
| | | | | | | | | | | | | In the process of debugging the last couple of commits (though I no longer remember exactly how) I noticed that 'wait-for-routine' only waits until the target routine stops running for any reason, including when it blocks on something. That's not the synchronization primitive we want in production code, even if it's necessary for some scenarios like 'buffer-lines-blocks-until-newline'. So we rename the old 'wait-for-routine' primitive to 'wait-for-routine-to-block', and create a new version of 'wait-for-routine' that say callers of 'start-writing' can safely use, because it waits until a target routine actually completes (either successfully or not).
* 3193Kartik K. Agaram2016-08-161-1/+19
| | | | | | | | | | | Bugfix: 'restart' should never restart completed routines. They will often have nothing to run. I ran into this while considering whether 'read' on channels to return true on success or failure. Switching from 'fail?' to 'success?' crashed. But now that it's fixed I think I'll keep things the way they are. No reason to be consistent with 'next-ingredient' and have the status be true to signal success.
* 3192Kartik K. Agaram2016-08-161-0/+28
|
* 3154 - reorg before making 'random' more testableKartik K. Agaram2016-07-271-0/+329