Examples from the presentation (with buggy executions elided):
02.scm | The thread running `serve' is the only one to touch `balance' |
04.scm | Channel value is can now be a request for the current balance in the form of c reply channel to receive the balance. |
05.scm | Step toward general strategy for making things thread-safe: create a channel, create a server, and create a safe-ifying wrapper. |
06.scm | Avoid mutation: just pass the current balance in a loop. |
07.scm | Instead of encoding deposit versus balance in the message, encode it in the choice of channel, which is more general (and, yes, tends to fit type systems better). |
08.scm | Use `sync' and `handle-evt' to clean up the dispatch. |
10.scm | Switch to queue example. [Bug: what if the queue is empty?] |
12.scm | Fix bug by ignoring dequeue requests if we have nothing to supply; use never-evt in that case. |
13.scm | Generalize queue code to support multiple queues. |
14.scm | Dequeue from q1 or q2, whichever is ready to supply an item. |
15.scm | Switch to an API that exposes events instead of channels, because that will compose better. |
18.scm | Now we can implementing a multiplex "queue" in terms of other queues. [Beware that the multiplexes one is not actually a queue anymore, because it doesn't preserve order, but maybe we don't care.] |
20.scm | Swap-channel example |
21.scm | A queue that accepts a predicate before supplying an item from the queue. The server now needs to keep a list of requests, and the synchronization point is the request response, not the request acceptance. |