about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 293 - unit test for misplaced deadlockKartik K. Agaram2014-11-221-0/+17
|
* 292 - back to state of commit 276Kartik K. Agaram2014-11-221-1/+1
| | | | | | | | | | | | | | | | 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.
* 291 - figured out the channel-handoff problemKartik K. Agaram2014-11-212-4/+11
| | | | | | | | '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.
* 290 - how was channel-write-block *ever* working?!Kartik K. Agaram2014-11-212-2/+6
| | | | Oh right, because I wasn't using default-scope when checking to wake up.
* 289 - finally back to deadlock detectionKartik K. Agaram2014-11-212-5/+27
|
* 288 - support sleeping while watching a memory locationKartik K. Agaram2014-11-212-3/+52
|
* 287Kartik K. Agaram2014-11-211-19/+21
|
* 286Kartik K. Agaram2014-11-211-5/+7
|
* 285Kartik K. Agaram2014-11-211-2/+1
|
* 284Kartik K. Agaram2014-11-211-9/+9
|
* 283Kartik K. Agaram2014-11-212-22/+25
|
* 282 - scheduler skips ahead when all routines are asleepKartik K. Agaram2014-11-212-30/+50
|
* 281Kartik K. Agaram2014-11-212-28/+36
|
* 280 - waking up sleeping routinesKartik K. Agaram2014-11-212-5/+47
| | | | Tests still hanging at some point.
* 279 - one new test passing, but sleep now hangsKartik K. Agaram2014-11-211-2/+5
|
* 278Kartik K. Agaram2014-11-211-0/+5
|
* 277 - back up, start refactoring the schedulerKartik K. Agaram2014-11-212-56/+119
| | | | | | | | | 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.
* 276 - now fork can take any argsKartik K. Agaram2014-11-192-2/+15
| | | | | | | | | 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.
* 275 - pass args to forkKartik K. Agaram2014-11-192-3/+15
| | | | Only literals for starters.
* 274 - long overdue test for 'fork'Kartik K. Agaram2014-11-191-0/+11
|
* 273Kartik K. Agaram2014-11-181-1/+1
|
* 272Kartik K. Agaram2014-11-181-1/+1
|
* 271Kartik K. Agaram2014-11-181-7/+7
|
* 270Kartik K. Agaram2014-11-181-2/+8
|
* 269Kartik K. Agaram2014-11-182-12/+30
| | | | | | 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.
* 268 - recursive function: factorialKartik K. Agaram2014-11-171-0/+15
| | | | | 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
* 267 - more intuitive channel capacityKartik K. Agaram2014-11-152-5/+6
|
* 266 - update htmlKartik K. Agaram2014-11-093-71/+560
|
* 265Kartik K. Agaram2014-11-091-1/+3
|
* 263Kartik K. Agaram2014-11-081-3/+4
| | | | | | | | | | | | | | | | | 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.
* 262Kartik K. Agaram2014-11-081-4/+4
|
* 261 - render matchadd() to html as wellKartik K. Agaram2014-11-082-54/+145
|
* 260Kartik K. Agaram2014-11-081-2/+2
|
* 259 - finally channel read/write can cause routine to sleepKartik K. Agaram2014-11-072-6/+74
|
* 258 - new channel helpers: empty? and full?Kartik K. Agaram2014-11-072-4/+118
|
* 257 - cleanup the narrative in mu.arc.tKartik K. Agaram2014-11-071-59/+103
|
* 256 - channel pointers can now wrapKartik K. Agaram2014-11-072-10/+82
|
* 255Kartik K. Agaram2014-11-071-3/+3
| | | | | As per 248, ignoring output values can reduce some of the pressure of dealing with raw locations.
* 254Kartik K. Agaram2014-11-071-0/+1
|
* 253Kartik K. Agaram2014-11-071-17/+17
|
* 252Kartik K. Agaram2014-11-071-3/+3
| | | | Single idiom for setting oargs.
* 251Kartik K. Agaram2014-11-071-5/+8
|
* 250 - experimental support for _ oargKartik K. Agaram2014-11-072-11/+33
| | | | | | | 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
* 249Kartik K. Agaram2014-11-071-2/+2
| | | | I've been meaning to fix that misleading label for some time now..
* 248Kartik K. Agaram2014-11-071-8/+8
| | | | | | | | | | 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?
* 247Kartik K. Agaram2014-11-072-3/+41
|
* 246Kartik K. Agaram2014-11-072-6/+17
|
* 245 - sanity check for type tableKartik K. Agaram2014-11-061-0/+8
|
* 244Kartik K. Agaram2014-11-062-2/+3
|
* 243 - robustify channel testsKartik K. Agaram2014-11-061-9/+15
|