[ python-Bugs-1010221 ] Run interrupt on controller loss tracked by a weakref

[noreply at pgfoundry.org]

Bugs item #1010221, was opened at 2008-01-05 22:35
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010221&group_id=1000094

Category: fe/proboscis
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: James Pye (jwp)
Assigned to: James Pye (jwp)
Summary: Run interrupt on controller loss tracked by a weakref

Initial Comment:
With the new protocol transactions, it is possible to assign "controller" objects to a given transaction as a weakref. The weakref is necessary because it is important to know when the interface to the result set no longer exists. When an attempt to process further transactions is made, a check can be done on the weakref to identify if the controller still exists; if it doesn't an exception should be raised and the current transaction interrupted(via .Interrupt()) notifying the user of the potential data/state loss and for large copies interrupting a very costly completion. Normally these situations would occur  when an interrupt occurs(signal or keyboardinterrupt).

For the most part, this would normally see action on ResultHandles running COPYs, and Portals on the initial execute.

----------------------------------------------------------------------

>Comment By: James Pye (jwp)
Date: 2008-03-14 10:35

Message:
After some thought, this actually conflicts with the ability to push out multiple protocol transactions in order to reduce roundtrips.

The problem is that if you push multiple transactions, and an exception or other caused a lost controller, there is no way for the protocol transaction manager to immediately know what will be interrupted. However, if protocol transactions are done one at a time, it knows what will be interrupted, if anything.

So, as a result, I'm going to close out the multiple pushes task. While it's not dead, it's also not a 1.0 feature. More thought needs to be given to how it would work with lost controller garbage collection.

----------------------------------------------------------------------

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010221&group_id=1000094