From: SourceForge.net <no...@so...> - 2012-12-31 11:19:26
|
Feature Requests item #3598875, was opened at 2012-12-29 10:21 Message generated for change (Comment added) made by ferrieux You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=360894&aid=3598875&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 10. Objects Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Nijtmans (nijtmans) Assigned to: Alexandre Ferrieux (ferrieux) Summary: new macro TclFreeIfRefCountZero Initial Comment: In various places, objects with refCount zero are not cleaned up in the error-case. See branch "novem-freeifrefcountzero" for a start, there are probably many more places where this macro is useful. Meant for Tcl 9. Ongoing. Inspired by the discussion regarding bug 3598580 with Alexandre Ferrieux. ---------------------------------------------------------------------- >Comment By: Alexandre Ferrieux (ferrieux) Date: 2012-12-31 03:19 Message: > Tcl_SetObjResult(interp, Tcl_NewIntObj(123)); > .... would have to become: > Tcl_Obj *resultObj = Tcl_NewIntObj(123); > Tcl_SetObjResult(interp, resultObj); > Tcl_DecrRefCount(resultObj); Unless, of course, the contract of SetObjResult is altered to *not* incrRefCount ! Obviously, after a decade of existence, the create-at-zero principle has pervaded all APIs, and I am not minimizing the cost of a switch. But a fair evaluation must take this "contamination" into account and allow for each solution to assume cooperation from the rest ;) > Code written for one pattern cannot be converted to the other > by macro. Yes, we've agreed to look at breaking things where > necessary, but this is a lot of breakage for very questionable gain. *This* is the winning argument ! Thanks for recording it here; now we can proceed with Jan's TclFreeIfRefCountZero macro, which respects the current semantics but allows for a cleaner refcount/lifecycle rule for objects: now they should only exceptionally die at -1. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2012-12-30 18:53 Message: (different "the code" in the two paragraphs; first is my code, second is Tcl source code) ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2012-12-30 18:52 Message: Alas, I can't provide factual backup for my assertions on complexity from the time; I didn't keep the code and the app it was part of was under a bizarre license anyway. The best thing to come out of it was a research line that lead to the canonical-list-invoke performance enhancements that went into Tcl sometime in 8.3 or 8.4. Oh, and pointing to the code is awkward as it isn't in fossil; you'll have to grab the tar archives off of SF (I think that's where we keep those files). ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2012-12-30 18:47 Message: Consider: Tcl_SetObjResult(interp, Tcl_NewIntObj(123)); That would have to become: Tcl_Obj *resultObj = Tcl_NewIntObj(123); Tcl_SetObjResult(interp, resultObj); Tcl_DecrRefCount(resultObj); There are a *lot* of other "simple" cases like that (e.g., appending an element to a known list) and the idiom is very common in Tcl itself. (For example, it is there in all of the error handling.) Dictionary construction is even worse. The cases that get slightly better are those where failures are possible in the "consuming" operation (such as Tcl_SetVar2Ex) but they just gain the ability to omit the Tcl_IncrRefCount from the explicit pattern; they still have all the complexity of dealing with the gory details. It also breaks code a lot. (This is from memory/experience; I wrote an OO extension — it was fast but hard to use — against 8.0a1 and maintained it through to 8.0.3 or so. The pain from switching over was high, but the code shortened quite a lot.) Code written for one pattern cannot be converted to the other by macro. Yes, we've agreed to look at breaking things where necessary, but this is a lot of breakage for very questionable gain. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2012-12-30 03:36 Message: Yes, I've been told about this already (and probably by you Donal ;). Would it be possible to be more precise and factual ? Please give, in this ticket's comment thread, concrete examples of the complex/slow idioms that it would/did entail. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2012-12-30 03:29 Message: The objects-start-with-refcount-1 approach was tried during the 8.0 alphas, and we switched to the current system as it greatly simplified most basic uses. (OK, it's in pre-history as it is from before the switch to CVS, but I wrote code against 8.0a1 as I desperately needed the performance boost, and I *remember* what it was like. You had to have a lot of temporary variables where now you can just feed objects directly into APIs like Tcl_ListObjAppendObj.) ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2012-12-29 10:39 Message: >"NewObj()_>refCount==1" for novem ? No, I don't think that's a good idea. (but feel free to prove me wrong in a separate branch) ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2012-12-29 10:29 Message: Interesting. But while we're at it, what about frankly switching to "NewObj()_>refCount==1" for novem ? I admit this will seriously threaten ABI compatibility. But is this still a concern for novem ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=360894&aid=3598875&group_id=10894 |