about summary refs log tree commit diff stats
path: root/075channel.mu
Commit message (Collapse)AuthorAgeFilesLines
* 3608 - concurrent writes to fake file systemKartik K. Agaram2016-10-291-0/+4
|
* 3552Kartik K. Agaram2016-10-221-1/+1
| | | | | | | | | | | | | | | | | | Stop requiring jump instructions to explicitly provide a ':label' type for jump targets. This has been a source of repeated confusion for my students: a) They'd add the ':label' to the label definition rather than the jump target (label use) b) They'd spend time thinking about whether the initial '+' prefix was part of the label name. In the process I cleaned up a couple of things: - the space of names is more cleanly partitioned into labels and non-labels (clarifying that '_' and '-' are non-label prefixes) - you can't use label names as regular variables anymore - you can infer the type of a label just from its name
* 3527Kartik K. Agaram2016-10-201-1/+15
|
* 3429 - standardize Mu scenariosKartik K. Agaram2016-09-281-21/+22
| | | | | | | | | | | | | A long-standing problem has been that I couldn't spread code across 'run' blocks because they were separate scopes, so I've ended up making them effectively comments. Running code inside a 'run' block is identical in every way to simply running the code directly. The 'run' block is merely a visual aid to separate setup from the component under test. In the process I've also standardized all Mu scenarios to always run in a local scope, and only use (raw) numeric addresses for values they want to check later.
* 3392Kartik K. Agaram2016-09-171-2/+2
| | | | Bugfix for the "remaining bug" mentioned in commit 3391.
* 3390Kartik K. Agaram2016-09-171-5/+5
|
* 3389Kartik K. Agaram2016-09-171-46/+46
|
* 3387Kartik K. Agaram2016-09-171-31/+31
|
* 3385Kartik K. Agaram2016-09-171-45/+45
|
* 3379Kartik K. Agaram2016-09-171-6/+6
| | | | Can't use type abbreviations inside 'memory-should-contain'.
* 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