| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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?
|
| |
|
|
|
| |
In the process I've uncover a couple of situations we don't support type
abbreviations yet. They're next.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|