Handling I/O callbacks using SSM threads

[j-hui]

Starting a thread here because I found this to be an interesting idea, and wanted to continue discussion asynchronously. This is a potential workaround/alternative to #8 .

In our meeting today, @koengit proposed handling I/O by spawning handler threads waiting for updates on the variable. My understanding of how this works would be as follows. Suppose we have a reference l :: Ref LED (perhaps obtained via some reference factory as @Rewbert proposed), and a writer thread w which writes to the LED:

-- running in w
l <~ LEDOn

A output listener thread o can handle this asynchronously:

-- running in o
wait [l] -- pick up the assignment from w
-- communicate with hardware after wait unblocks

To handle instaneously assignments, o must run at a lower priority to w; otherwise, the write to l would be lost.

The concern @sedwards-lab had is that if the priority of o is lower than a process with some expensive (but logically instantenously) computation, the wallclock time at which the handler is invoked may be unnecessarily delayed. So, for instance, consider a busy process b whose priority in relation to w and o is:

w > b > o

w runs first, writing to r and scheduling o to run later. However, it does, the higher priority b executes first and stalls the execution of o, even if b is not at all related to o.

Is this an accurate summary of the idea and the issues we think may arise from it?

[j-hui]

For the previous example, one could cast blame on the programmer for arranging the priorities in such a way that confounds the performance of the program, but it does appear we may be able to do better. If b and o are truly independent (process order does not matter), and b isn't also perform direct I/O, we might be able to avoid the latency due to b by scheduling o first.

I'm suggesting this because I had studied some prior work in "time warp" scheduling strategies, which may help us here. In particular, even though the semantics of the language say that processes are totally ordered, I believe we can justify an out-of-order implementation as long as the behavior is functionally equivalent. Just a thought.

[j-hui]

This particular line of discussion hasn't really gone anywhere but the subject will be kept alive in #26 . Closing this, but will summarize that it represents a lazy output implementation (as opposed to a strict one).