STM help

[Simon Marlow]

The problem seems to boil down to this:

  - write a thread that performs an IO action whenever the contents
    of a set of TVars changes.

Providing this functionality as part of STM seems to be wrong, because
it relies on a particular implementation of STM (or a simulation of that
behaviour).

It would be difficult to incorporate this in the semantics, because the
semantics doesn't currenly say anything about the change-detecting
optimisation - so the behaviour of the new combinator would have to be
specified explicitly.

Another purely STM solution that you didn't mention is this:

  - have one TVar that records the "something changed" condition; every
    write to a TVar in the widget tree also sets this flag to true;
    the updater thread waits for the "something changed" flag to
    become True, calculates the screen redraw, then sets the flag to
    False again.

  - The difficulty then is optimising away the redraws when only hidden
parts
    of the widget tree have changed - you could do this by having a
"visible"
    flag on every widget, set by the updater thread.  If an update
occurs to a
    hidden widget, the changed flag is not set.  If a widget changes
such that
    it might have become visible, it must set the changed flag.

I know this is an extra TVar per widget and more operations for each
update, but I think it's the right thing.  There are no unnecessary
traversals of the widget tree, and redraws happen no more often than
necessary.

Cheers,
	Simon

On 03 July 2005 20:17, John Meacham wrote:

> I am attempting to use the STM to rewrite the screen handling code in
> ginsu, which frankly, I am a little embarassed of :)
> 
> The basic needs are:
> - fully concurrent
> - all curses calls must go through a single thread (otherwise it gets
>   real complicated)
> - atomic updates to multiple parts of the screen at once.
> - efficient update mechanism, screen _must not_ be needlessly redrawn.
> 
> 
> So, my idea was basically,
> 
> have a screen update thread, this is the only one that will make
> curses 
> calls.
> everything else communicates with the screen by modifying TVars
> holding 
> data values like so
> 
> data Widget = HBox { subWidgets :: [TVar Widget] } | Text { body ::
> TVar String } 
> 
> and the screen is represented by a top level 'TVar Widget'
> 
> 
> 
> This gives the first three requirements very nicely, you can
> atomically 
> update several widgets or tex boxes, and everything is very concurrent
> in a good way.
> 
> The problem comes in when trying to implement an efficient update
> mechanism, the problem is that I can't figure out how to wait on only
> the relevant changed TVars.
> 
> The structure of my curses thread would look like (essentially):
> 
> 
> cursesThread head = do
>         atomically $ do
>                 tv <- readTVar head
>                 doit <- render tv  -- returns an IO action
>                                       which draws the screen,
>                                       calling readTVar on subwidgets.
>                 return doit
>         doit
>         -- What to put here to block on relevant changes?
>         cursesThread head
> 
> The problem is that many TVars may contribute to the final screen, one
> can change a TVar several widgets down and the screen should be
> updated. 
> In addition, the screen should not be redrawn if a TVar for an
> offscreen 
> or hidden widget changes. other threads should be able to update state
> without worrying about the UI.
> 
> Now, i can think of a couple things, neither of which I like very
> much. 
> 
> - create a wrapper monad around STM that accumulates a list of TVars
>   read. This is just unappealing for a variety of reasons.
> - have render return some sort of keys to compare values too and retry
>   if they are all equal to their old values. this would
>   double the work, one pass to draw it, another pass to figure out we
>   need to block. it would also really complicate the code.
> 
> 
> Now, the other reason these options are undesirable, is that the STM
> mechanism collects the exact information I need. AFAIK there is just
> no 
> way to get at it. the STM must keep a log of all TVars read in order
> to 
> know what to wait on when retrying. What I need is a way to somehow
> atomically commit (assuming the transaction succeeds) and then be able
> to block on the depended on TVars
> 
> 
> This could be done with the addition of a simple primitive:
> 
> - | behave exactly like 'atomically' except after the transaction
>   succeeeds, run the action on the result, and then block until
>   one of the TVars read by the transaction changes.
> 
> atomicallyBlock :: STM a -> (a -> IO b) ->  IO b
> 
> 
> I think this could be very useful in general, but perhaps there is
> something I am not seeing? I am still figuring out idioms to use with
> STM.
> 
> 
>         John