Sorry that I took the thread off the list - not my intention... Quoting [Thilo Kielmann] (Jul 15 2006):
Making a copy of the context does not help. The problem, as said, is that the 'remove_context' can get called before or while that context is used, and that needs to have a well defined semantic in the (lang independent) spec.
Having it a user level error is an option. Well, not really an error, but what you say (I think) is that the later operations on that object cannot use the Globus context - right?
Right, we agree. If there are more/other contexts that might still be OK. IMHO, if the programmer is removing a context that is still needed, that is a mistake that might lead to an error.
Yes, we could do that, agree. However, we are already going a different route with sessions and tasks: -------------------------------------------------------- saga::task t; { saga::session s; saga::file f (s, url); t = f.copy saga::task::Task (target); } t.run (); // session and file object are gone here - however, the // task still lives, and keeps the session and object // resources alive. At least some state must be // maintained internally -------------------------------------------------------- As usual, that example is in C++, but the problem is independent of the language. I think that this is the same problem really as with the context. I think we should solve the the same way. The problem really is, I think, that the above example is the dominating one. Tasks, as they represent async ops, are bound to get passed around through different scopes, and it would be burdensome to expect the programmer to keep all associated objects, sessions and contexts etc. alive. Well, thats IMHO at least - what do you think? Cheers, Andre. -- "So much time, so little to do..." -- Garfield