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
--
John Meacham - ⑆repetae.net⑆john⑈
