`resetCycles` should be (more) immediate

[yaxu]

resetCycles resets the start time (to 'now') and tick count (to 0), so could in theory happen at now+latency time, regardless of the value of cFrameTimespan.

However if cFrameTimespan is set to e.g. 1, there is an unpredictable delay of between 0 and 1 seconds on top of latency. This seems to because the thread is delayed in the tick function, and so no input is processed between frames.

Instead of using threadDelay, it seems it's possible to do timeouts with STM. So tidal could wait for an action to process until the end of the frame.

I've not done any work with STM before and it looks like this would need an adjustment to how the queue is done currently? In the current implementation the TVar always contains a value so there's nothing to 'wait' for (without continuously polling for something other than a NoAction).

Does that sound like a reasonable analysis @Zalastax ?

[yaxu]

It seems I misunderstood how registerDelay works. It creates a separate state variable, and you somehow combine it with your STM action to create the timeout:
https://gist.github.com/qnikst/2762191

But still I think the model needs adjusting so that there can be a read action that times out if there isn't a new action.

[yaxu]

As a first step I switched to TQueue in #1198

I'm not entirely sure what I'm doing but this, I'm not sure of drawbacks but should allow a blocking call with timeout.

Using registerDelay will also require compiling with -threaded, I'm not sure if there are drawbacks to that either.