Better locking?

[rjkroege]

Many of the subtle bugs (e.g. #308) seem to be related to locking of the tree of Texts. I have been thinking about how to fix this. The sprinkling of mutexes all over Edwood doesn't seem very principled. There is a required lock acquisition/release order that isn't always followed by all code paths. This also doesn't seem very idiomatic.

Idea:

• Goroutine per Text
• Goroutine owns the tree of Text instances
• Goroutines handle events and queue (via channel) for finding the Text and then queue for Text mutation (controlled via channel)

Maybe this is way too complicated. Anyway: thoughts welcome on this.

[paul-lalonde]

I don't think that's too complicated at all. It roughly matches what I was thinking of when I was transliterating that code.
It forces us to identify mutations throughout the code (easy, though tedious) and put an interface around them. The synchronization via chans is natural, and the real perf bottlenecks are really in the buffer representation, which I hope Cameron will address.

[rjkroege]

OK. I think it will fix a bunch of bugs. I just need to figure out how to stage this in a way that doesn't turn into a giant hairball of a CL.