[KCP] Thoughts on adding system changes and refactoring ChangeSet

Stephen Pair stephen at pairhome.net
Wed Jun 25 13:33:23 UTC 2003


Andreas Raab wrote:

>>>Do you have any first-hand experience with those problems?
>>>      
>>>
>>Yes...as best I can remember, here are some challenges that I 
>>encountered:
>>
>> - process safety issues [...]
>>    
>>
>
>Yes, that's a real problem, or actually two. One of them is the ability to
>observe a (long-) running process while it is presumably running atomically.
>I don't think there's a lot which can be done here short of TeaTime (which
>is one the places where I'd like to use it). 
>

I think TeaTime is probably the only hope you'll have of solving that 
problem in a general way.  To expect the designer of some (significant) 
subsystem to anticipate every possible concurrent usage scenario is 
probably too much to ask.  (on a side note: one thing I've never really 
thought about is how you might combine a traditional concurrency scheme 
(using locking) and a transactional system (like TeaTime) into a common 
framework that is smart about knowing when a transaction is really 
needed and when it can optimize the transaction away because a subsystem 
is explicitly managing concurrent access).

>The other one is the question
>whether we can effectively encourage people to write "non-atomic" long
>running processes by default. There are some ways of doing this, for example
>encouraging event-driven loops instead of others. I haven't really
>experimented with this but I think for many situations the latter might be
>quite sufficient.
>

Not quite sure I follow you on this...can you explain this a little more? 

<tangent> One of the problems that I always struggled with was where 
transaction boundaries (begin/commit) belonged in the system...there 
some obvious places, but then there are many other non-obvious 
situations.  The only thing I could come up with was that events in the 
system should always happen atomically (and thus be performed implicitly 
in a transaction)...I think that holds for events originating outside 
the system (i.e. keyboard and mouse gestures) as well as event generated 
internally within the system. Is that by chance how TeaTime/Croquets 
works? </tangent>

>> - events propogating in endless loops [...]
>>    
>>
>
>I think that's only a problem if programmers have to write the notifications
>themselves. It's not very hard to prevent back- (or circular) propagation of
>events if you think about it a little and so the architecture really ought
>to support this and not require the programmer to invent it anew everytime
>you use it.
>

Yes, that's the simple case and is simple to solve, but what about more 
complex situations where the loop is less obvious.  How would you handle 
that?  Maybe CMD-. (as you mentioned) is sufficient.  It might also be 
useful to detect event loops, somehow break the cycle, and throw an 
exception.

>BTW, there are some interesting issues with endless event propagation in
>networks with conflicting constraints. I thought about it for a long time in
>Tweak and then it turned out that going fully multi-threaded solved this
>problem implicitly for me. Why? Because it means that each propagation link
>_is_ a process - when you have an endless chain you simply hit CMD-. which
>interrupts the current process (the link in the network). Even if you have
>many conflicts going on at the same time you can just hit CMD-. until enough
>links have been broken for the system to become responsible again. I can't
>even count the number of times this saved me when I was debugging this stuff
>;-)
>

That is very cool.  Maybe you could detect and kill the event processes 
automatically (and throw an exception).

>[and now you're probably also beginning to understand why I'm so happy that
>Squeak's processes are extremely lightweight and that process switches are
>sooo incredibly fast]
>

Absolutely.

>>- tools, tools, and more tools [...]
>>    
>>
>
>Yes, yes, yes! ;-) Absolutely. Partly because you're taking away something
>from the programmer (the ability to step directly into a response to some
>message) so you really need something that helps explaining about "what the
>hell is going on". Adam is currently working on a "heartbeat" for Tweak
>which I imagine to become the ultimate tool for visualizing events and
>explaining what is going on in the system.
>

Can't wait to see it...we had some ideas along those lines 
(visualization of events), but never got the opportunity to do any work 
on it.

>>This in combination with a transactional system (each component
>>could have a transactional context) enabled us to create UIs with 
>>very little work and in a very short period of time.  The framework
>>would allow us to open two UIs on the same system of objects and have
>>every aspect of the two UIs fully synchronized (text boxes, scroll bars,
>>check boxes...everything)...if you wanted to keep the two UIs in
>>isolation, you simply opened them in the context of separate 
>>transactions (OK and Cancel translated directly into Commit and Abort).
>>    
>>
>
>The point about the transactional context is interesting. Can you say a
>little more about what the transactional context defined and how it was
>determined? 
>  
>

Sure.

>It sounds somewhat like some of the thread-local variables I'm
>using in Tweak where we really want to determine various bits of information
>based on the current thread we're running in (this is partly motivated by
>things like the need to transfer certain state between processes; e.g., when
>some user clicks on an object a response to the click may need to obtain
>information about this user even in the absence of having it passed
>explicitly - and since it's multi-threaded I cannot rely on static globals
>so all of them must be process-bound).
>

That's exactly what we were doing...though I would encourage you to look 
at DynamicBindings for keeping thread-local variables (DynamicBindings 
is an evolution of something that I built explicitly for Kats to allow a 
transaction to be associated with a Process).  So, in our system a 
"component" (which as I mentioned before is a sort of flattened view of 
a network of objects where properties and events are promoted out of the 
network up to the component) could have a transactional context.  Any 
time you access (get or set) properties of that component, the component 
would switch the transactional context (of the current thread) and then 
use the value-net to access the real property in the domain model.  
Thus, any changes to the domain model would be affiliated with the 
transaction context of the component.  Any observed state would be the 
state as it exists for that transaction.  Events also needed to be 
"transaction aware" (in the sense that if I change the state of an 
object in one transaction, the event would not propogate to dependents 
in another transaction (since the state has not changed in the other 
transaction)).  So, with the value net stuff we wanted to be able to 
have multiple objects to keep aspects of their state synchronized...as 
soon as we added that, we realized that we also wanted to be able to 
have better control over that synchronization, which is how the 
transaction system got started.  We had this working (more or less) over 
the network as well...so a user on one machine that was looking an a GUI 
on some network of objects would see real time changes as someone on 
another machine manipulated another GUI on the same set of objects.  It 
was neat (at the time) to show a demo where sliders/scrollbars/checkboxs 
being manipulated on one computer would update in on another...that in 
and of itself was neat, but the real wow factor came when we showed 
people how little code was required to achieve it.  Of course, now it 
all pales in comparison with Croquet.

- Stephen



More information about the Squeak-dev mailing list