| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Also mirror mu.arc.t.html to the gh-pages branch.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This simplifies things a lot and eliminates the race condition.
I think it's practical too, as long as you save a single location and
don't permit sleeping on compound structures. I'm resigned to needing a
lock in the native setting.
Should I be concerned that I fixed a failing test by getting rid of hit?
If I had alternatives, how would I save the old sleep implementation?
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Still failing, but worth memorializing for posterity.
Race condition tests are still experimental, even more tied to a very
specific implementation. If I make changes to 'write' the very
'wipe-read' label will go away.
But then you just delete all tests relying on stale labels and try to
think up new race conditions.
|
| | |
|
| |
|
|
|
|
|
|
| |
The hope is that those labels will help us test the race condition by
hooking into the scheduler.
Hooking into the scheduler will complicate the task of dropping racket
and running tests natively. But we'll worry about that later.
|
| | |
|
| |
|
|
|
|
| |
Also uncovered a bug in convert-braces, which helps see a simpler
close-offset. Instead of all that crap with first incrementing then
waiting for counter to return to 0, just wait for counter to go to -1.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Was already working, test was just stale. Reassuring.
|
| |
|
|
|
| |
Too hard to canonicalize routines in traces, with their nested tables.
Give up for now.
|
| |
|
|
| |
But handoff test still failing.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|