Fwd (kielmann@cs.vu.nl): Re: [saga-rg] SAGA, object states, and concurrency
All, the (my) aim of the current discussion is to separate SAGA-related issues from language-specific issues. SAGA-related issues belong to the SAGA spec, the others to specific language-bindings docs. In this context, I am concerned about sections 1.3.6 Object State 1.3.7 Life Time Management 1.3.8 Freeing of Resources and Garbage Collection about 1.3.6: it is not clear (to me ;-) why prev. error condition and callbacks MUST NOT get copied can anybody give a motivation for this, please? (and include it in the document) about 1.3.7.: as I wrote earlier, this should simply become:
The SAGA specification does NOT address issues of object life cycle and memory management at all. It is subject to the language bindings of SAGA to define this in a way that suits the respective programming languages.
about 1.3.8: I am worried bout the last sentence. Please make a link to section 1.5 Otherwise, I am afraid, this might open the door to "weakly compliant" implementations. Thilo -- Thilo Kielmann http://www.cs.vu.nl/~kielmann/
Quoting [Thilo Kielmann] (Aug 03 2006):
it is not clear (to me ;-) why prev. error condition and callbacks MUST NOT get copied can anybody give a motivation for this, please? (and include it in the document)
just about that for now: - about the error condition: I think it makes sense to start a new object instance with a clean error record. I am not sure though - either way is fine with me. - about the callbacks: callbacks have a simple way to avoid getting called twice (they get removed on returning false). By copying the cb's to the new instance, that mechanism is effectively disabled (the cb can be called on both instances, hence twice). Also, a cb is a application level object, so the SAGA implementor has no control whatsoever on how large that object is, and copying can be very expensive. Cheers, Andre. -- "So much time, so little to do..." -- Garfield
Thanks for the quick answer. On Thu, Aug 03, 2006 at 12:53:25AM +0200, Andre Merzky wrote:
- about the error condition: I think it makes sense to start a new object instance with a clean error record. I am not sure though - either way is fine with me.
Maybe we should not call this "copy"? What would be the meaning (the reason for) this copy? Create a clone? Or a facsimile??? Is there a word from pattern-speak describing this??
- about the callbacks: callbacks have a simple way to avoid getting called twice (they get removed on returning false). By copying the cb's to the new instance, that mechanism is effectively disabled (the cb can be called on both instances, hence twice). Also, a cb is a application level object, so the SAGA implementor has no control whatsoever on how large that object is, and copying can be very expensive.
In this case, that would make sense NOT copying it. However, we need a cross ref to the section on callbacks, then. BTW: Looks like we need a whole lot of cross refs all over the place??? Cheers, Thilo -- Thilo Kielmann http://www.cs.vu.nl/~kielmann/
Quoting [Thilo Kielmann] (Aug 03 2006):
On Thu, Aug 03, 2006 at 12:53:25AM +0200, Andre Merzky wrote:
- about the error condition: I think it makes sense to start a new object instance with a clean error record. I am not sure though - either way is fine with me.
Maybe we should not call this "copy"? What would be the meaning (the reason for) this copy? Create a clone? Or a facsimile???
Clone in the sense of deep-copy would make sense.
Is there a word from pattern-speak describing this??
- about the callbacks: callbacks have a simple way to avoid getting called twice (they get removed on returning false). By copying the cb's to the new instance, that mechanism is effectively disabled (the cb can be called on both instances, hence twice). Also, a cb is a application level object, so the SAGA implementor has no control whatsoever on how large that object is, and copying can be very expensive.
In this case, that would make sense NOT copying it.
Hmm, right, that is what we say :-)
However, we need a cross ref to the section on callbacks, then.
BTW: Looks like we need a whole lot of cross refs all over the place???
Yes, probably. A.
Cheers,
Thilo
-- "So much time, so little to do..." -- Garfield
After all responses I have seen were about 1.3.6 and 1.3.8, can we assume 1.3.7 to be agreed upon?
about 1.3.7.: as I wrote earlier, this should simply become:
The SAGA specification does NOT address issues of object life cycle and memory management at all. It is subject to the language bindings of SAGA to define this in a way that suits the respective programming languages.
Thanks, Thilo -- Thilo Kielmann http://www.cs.vu.nl/~kielmann/
Hi Thilo, Quoting [Thilo Kielmann] (Aug 04 2006):
After all responses I have seen were about 1.3.6 and 1.3.8, can we assume 1.3.7 to be agreed upon?
1.3.7 is adressing deep/shallow copy behaviour - but it might be that numberation changed meanwhile. I reformulated 1.3.8. 'Object Life-Time' in terms of state ('Object State Life-Time'). That is probably closer to what you want. Hartmut and I discussed the topic once more, and Hartmut proposed to formulate that in pre- and post-conditions to method calls. That would remove any notion of language specifica, while keeping the general idea in place. I'd like to apply that notion to the text next week, and lets see how you (and others) like it. Is that ok with you? Cheers, Andre. PS.: I pondered about your remark in respect to code snippets again, and I'm afraid that I strongly disagree here: I think application level code and semantics is all that matters to SAGA really. I can throw in more perl examples if you want, or C, to avoid the impression that its all about C++ (which it isn't), but I definitely think that testing the spec against simple use cases (that is what the snippets are) is a must.
about 1.3.7.: as I wrote earlier, this should simply become:
The SAGA specification does NOT address issues of object life cycle and memory management at all. It is subject to the language bindings of SAGA to define this in a way that suits the respective programming languages.
Thanks,
Thilo -- "So much time, so little to do..." -- Garfield
Hi,
1.3.7 is adressing deep/shallow copy behaviour - but it might be that numberation changed meanwhile.
indeed, another section got inserted. We are talking about 1.3.8 now. (I just got the current state out of CVS.)
I reformulated 1.3.8. 'Object Life-Time' in terms of state ('Object State Life-Time'). That is probably closer to what you want.
A little closer, but not really. Of 1.3.8., I agree with the first paragraph. The second paragraph, up to and including the item list is still C++-minded. Why isn't it as easy as: if you give parameters to SAGA methods, esp. to tasks, you have to make sure that these parameters will be available (read: not deleted) while they are still needed? -- and do so "as natively expected in the respective language", to cite the first paragraph. The final paragraph of 1.3.8 is simply wrong, because: A SAGA implementation MUST NEVER explicitly free resources of parameters to its methods.
PS.: I pondered about your remark in respect to code snippets again, and I'm afraid that I strongly disagree
sorry, which remark ???
here: I think application level code and semantics is all that matters to SAGA really. I can throw in more perl examples if you want, or C, to avoid the impression that its all about C++ (which it isn't), but I definitely think that testing the spec against simple use cases (that is what the snippets are) is a must.
Thilo -- Thilo Kielmann http://www.cs.vu.nl/~kielmann/
Rethinking:
A SAGA implementation MUST NEVER explicitly free resources of parameters to its methods.
I think that is going too far. In some languages, this might be necesaary while in others the MUST NEVER would apply. There are several, incompatible object life time schemes around, and we have to serve all possible (useful) language bindings. In an effort to be constructive, I have modified the text in the CVS repository, trying to find a wording that serves all languages. Thilo -- Thilo Kielmann http://www.cs.vu.nl/~kielmann/
participants (2)
-
'Thilo Kielmann' -
Andre Merzky