diff options
author | Joey Hess <joey@kitenet.net> | 2013-10-08 18:14:11 -0400 |
---|---|---|
committer | Joey Hess <joey@kitenet.net> | 2013-10-08 18:14:11 -0400 |
commit | fb449ad0c5af7d6aff2fb129fc265f11c08ac3fe (patch) | |
tree | ad16cfd006b20395231eb3c952b6dfa21d3c3b0f | |
parent | f2ab80def176a2eb00c353d3cdce20dedde2445d (diff) |
devblog
-rw-r--r-- | doc/devblog/day_30__cronner.mdwn | 17 |
1 files changed, 17 insertions, 0 deletions
diff --git a/doc/devblog/day_30__cronner.mdwn b/doc/devblog/day_30__cronner.mdwn new file mode 100644 index 000000000..f368407ca --- /dev/null +++ b/doc/devblog/day_30__cronner.mdwn @@ -0,0 +1,17 @@ +Lots of progress from yesterday's modest start of building data types for +scheduling. Last night I wrote the hairy calendar code to calculate when +next to run a scheduled event. (This is actually quite superior to `cron`, +which checks every second to see if it should run each event!) Today I +built a "Cronner" thread that handles spawning threads to handle each +scheduled event. It even notices when changes have been made to the its +schedule and stops/starts event threads appropriately. + +Everything is hooked up, building, and there's a good chance it works +without too many bugs, but while I've tested all the pure code (mostly +automatically with quickcheck properties), I have not run the Cronner +thread at all. And there is some tricky stuff in there, like noticing +that the machine was asleep past when it expected to wake up, and deciding +if it should still run a scheduled event, or should wait until next time. +So tomorrow we'll see.. + +Today's work was sponsored by Ethan Aubin. |