about summary refs log tree commit diff stats
path: root/075channel.mu
Commit message (Collapse)AuthorAgeFilesLines
* 3353Kartik K. Agaram2016-09-151-0/+5
| | | | | | | | | | | | | Fix failing scenarios in channel layer. We do so by introducing a kludgy new instruction to explicitly signal when a routine is stuck ('blocked') and waiting on another. All this locking and blocking may well be a crap design. We'll see if we find ourselves using these primitives again. Ideally we don't need them for anything else now that we're done building channels. Still some failing scenarios left in chessboard.mu. Let's see how that goes.
* 3351 - new but incomplete synchronization setupKartik K. Agaram2016-09-141-21/+39
| | | | | | | | | | | | | Previously our channels were based on an unconventional `wait-for-location` primitive that waits for a specific address to change its contents. This only works as long as a channel has a single reader and a single writer routine. To support multiple readers and writers we switch to a more conventional compare-and-set primitive. There's still a couple of failing scenarios, though -- the ones using `wait-for-routine-to-block`, because the new approach never blocks on an empty or full channel, just yields CPU for a time before polling. Hmm, how to fix this?
* 3337 - first use of type abbreviations: textKartik K. Agaram2016-09-121-1/+1
| | | | | In the process I've uncover a couple of situations we don't support type abbreviations yet. They're next.
* 3258Kartik K. Agaram2016-08-261-4/+4
| | | | | | | | | | | | | 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).
* 3231 - reading from fake files in scenariosKartik K. Agaram2016-08-201-0/+2
|
* 3225 - testable interface for writing filesKartik K. Agaram2016-08-181-1/+0
| | | | | | | | For example usage of file operations, see filesystem.mu. Is it ugly that we don't actually write to disk unless we wait for the writing routine to exit? Maybe there's a nice way to wrap it. At any rate, all buffering is explicit, which seems a win compared to *nix.
* 3194Kartik K. Agaram2016-08-161-2/+2
|
* 3154 - reorg before making 'random' more testableKartik K. Agaram2016-07-271-0/+452