| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
What have we learned?
a) You can't detect deadlock between running a thread and waking up
sleeping threads -- you may miss threads that are about to become
available.
b) Most of the context-switching code in 'run' shouldn't assume
routine* is correctly set. That's just for 'run-for-time-slice' and
for checking on blocked threads. I was implicitly requiring it when I
shouldn't, and not setting it when checking blocked threads.
Before I fix the next failing test I want to write unit tests for a)
above.
|
|
|
|
|
|
|
|
| |
'read' and 'write' pass in the channel by value, so they block on
different *local* variables.
Does this kill my plan to pervasively use call-by-value everywhere? No,
we might be able to salvage it if channels are the only shared pointers.
|
|
|
|
| |
Oh right, because I wasn't using default-scope when checking to wake up.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Tests still hanging at some point.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
In trying to share pipes between routines, I realized my scheduler was
actually quite brittle. Changing scheduling-interval* shouldn't be
required in most tests, and shouldn't change the outcome most of the
time.
Current state: all scheduler tests fail, but everything else passes.
|
|
|
|
|
|
|
|
|
| |
No oargs, though. Hopefully we don't need them. Use channels for
passing data back.
Drawback: channels must all be passed in by value, and their direction
isn't obvious. Hard to tell when multiple threads read/write the same
channel. Hopefully it's amenable to static analysis.
|
|
|
|
| |
Only literals for starters.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Minor cleanup and code comments.
I'm starting to feel the need for formatting primitives, so I don't
use comments just to provide section headings.
|
|
|
|
|
| |
Is this really harder to reason about by being somehow 'operational' and
'abstraction free'? http://cacm.acm.org/magazines/2010/8/96632-an-interview-with-edsger-w-dijkstra/fulltext
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm trying to think about how to write a test for the race condition,
and how to fix it. One thing that's been hard is even remembering where
it lies. It's not between wiping the watch and sleeping on it; that's
innocuous because the sleep would just immediately wake up. No, the race
condition lies between the empty check and the wipe.
For the innocuous race we could just create an atomic wipe-and-sleep.
But the more serious race requires a lock.
If we need a lock anyway, is there any reason to have two watch
variables?
I'm going to preserve these alternative functions in the code.
Alternatives will only ever be called from other alteratives or tests.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
As per 248, ignoring output values can reduce some of the pressure of
dealing with raw locations.
|
| |
|
| |
|
|
|
|
| |
Single idiom for setting oargs.
|
| |
|
|
|
|
|
|
|
| |
This radically overhauls our assumption that args must always be lists,
so we're probably missing things. Where we do, more tests are required.
Only important trace change: .traces/dummy-oarg
|
|
|
|
| |
I've been meaning to fix that misleading label for some time now..
|
|
|
|
|
|
|
|
|
|
| |
I've been using raw locations to make tests easy to read (test checks
the same locations that code modifies). But this means I have to manage
them myself, and I've been shoving variables into the storage for
compounds like tagged-value. Doesn't matter in this case since we don't
look at the contents of the tagged-value, but still unhygienic.
Maybe we need syntax for ignoring some output values?
|
| |
|
| |
|
| |
|
| |
|
| |
|