[Vm-dev] (no subject)

[Ben Coman]

I have had an idea brewing for a while... its not fully formed but I
just wanted to get some of it out of my head to check how
(im)practical it may be... and I may also misunderstand how
immutability will be used...

Background:
In a recent thread on delayed Transcript output from a loop in
Workspace someone made a passing comment about having the rendering
loop in its own thread.  This might not be the best solution for
Transcript, but it got me thinking that this might be beneficial
anyway.  However Morphic is not so good with parallel threads. In
particular its #drawOn:  methods seem to assume a single thread.

I've been involved in hunting some bugs in Pharo where... a UI forked
thread ended up calling #changed: such that the rendering data used by
#drawOn: in the main UI thread changed half way through, resulting in
the red-square-of-death.  Now the poster-child of parallel programming
is functional programming, so I had a passing thought that the
rendering would be safer using a more functional pattern - with
#drawOn: and any sub-calls only using an ivar or accessor once, and
passing data as method parameters rather than re-calling accessors
multiple times, since that might return different data if changed by
another thread.

Spur getting immutability is a big step towards supporting a
functional programming style. The main effect of this is presumably to
raise an error when assigning within an immutable object.   Maybe it
is enough if coding a new domain where you control the architecture,
but to convert an existing architecture the problem is not knowing
exactly which polymorphic objects you might be dealing with, some of
which might not be immutable.  As I understand it, immutability only
applies to a particular object's ivars and not recursively into the
objects held by those ivars.  So I could write a great functional
style #drawOn: method, but several objects deep is a mutable
collection that can be changed by other threads.  A big problem here
is this condition might lurk in the shadows unknown, and so I was
considering a way fail-early to expose this condition.


Question:
Rather than just raising an error when assigning to an ivar within an
immutable object, is there *any* way we could raise an error when
reading from a mutable object?  And also configure this on a
per-thread basis?

This way we could, for example, ensure a separate rendering thread
dealt only with immutable objects (by failing-early as the
architecture evolved from what it is now).


Perhaps just passing an immutable deep-copy  to the #drawOn: is
easier, but I wonder if this might have too much overhead.

cheers -ben