Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re^4: How should a fork of DBIx::Simple be handled?

by metaperl (Curate)
on Aug 31, 2011 at 11:22 UTC ( #923403=note: print w/ replies, xml ) Need Help??


in reply to Re^3: How should a fork of DBIx::Simple be handled?
in thread How should a fork of DBIx::Simple be handled?

So the only lesson you take away from these two threads is to continue avoiding direct contact with Juerd?

No not at all. I wasnt getting any email replies from him. I sent him a test case via email. He ran it and it worked for him. So I revised it and tye tried it and saw the problem and I sent him the fixed one. And he has said nothing since then via email, so I filed it as a RT ticket. And there has been no movement on the RT ticket I supplied a few weeks ago. But since he replied to me here, it seems that he is willing to work with me in some fashion. And I will definitely keep him in the loop. Although I prefer he stay in the loop by following me on github.

And his (and your) insistence on paying money for rapid feedback means I'd rather just do everything on my own because I have urgent demands for rapid evolution of this module and can no longer play backseat and/or pay money.

I'm still wondering what your goal is with these posts.

Hmm, well I wanted to get a feel for what (not)? to do and how (not)? to do it. The most likely thing to occur is that DBIx::Simple will be forked and I will document each change as I commit on github. I wont make any sort of CPAN release for a long time because we just need changes locally now. Over time, the various things I do might make their way into his code or a separate module.

But the issue that my bug raises is actually a point of divergence. I dont think he will ever accept that patch and change his code to quit using fiddling with reference counts. And my test case MUST work for what we are doing locally.


Comment on Re^4: How should a fork of DBIx::Simple be handled?
Re^5: How should a fork of DBIx::Simple be handled? (selective comprehension)
by tye (Cardinal) on Aug 31, 2011 at 13:52 UTC

    Are you going to call your fork DBIx::Simple::CircularReferences or DBIx::Simple::NeverDestroys?

    and tye tried it and saw the problem

    What I "saw" was that you should simply stop writing code that destroys the container object if you want to keep using one of the contained objects. But you insist on making a simplistic change to the DBIx::Simple module and not making a trivial change to how you use that module, even after I made it quite clear that your proposed change breaks the lifecycle management of the module.

    Unless you proposed a patch that fixed your "bug" without creating circular references, I would make the next "movement on the RT" to close it as "working as designed".

    - tye        

      Are you going to call your fork DBIx::Simple::CircularReferences or DBIx::Simple::NeverDestroys?
      LOL! your research concluded that my fix does indeed prevent a bunch of stuff from being cleaned up until Perl's "global destruction". which is fine with me. you can see my reasoning on reference count and I dont really see anything wrong with it, do you?
      What I "saw" was that you should simply stop writing code that destroys the container object if you want to keep using one of the contained objects.
      Are you implying that my method chaining and the resulting destruction was unsound?
      Unless you proposed a patch that fixed your "bug" without creating circular references
      Did you demonstrate that my patch creates circular references?
        you can see my reasoning on reference count and I dont really see anything wrong with it, do you?

        Yes. You assert:

        6. D goes out of scope, reference count for D drops to 0 and D is extinguished

        I showed that what actually happens is more like:

        6. D goes out of scope. Nothing happens.
        N. (Much later) Global destruction finally fires and a bunch of stuff finally gets destroyed, forcibly breaking the circular references

        my fix does indeed prevent a bunch of stuff from being cleaned up until Perl's "global destruction". which is fine with me. [emphasis added]

        So you don't care about making circular references? The consequence of making circular references is that destructors don't fire until global destruction. You don't appear to understand that.

        Some reasons why I don't find acceptable the delaying of destruction until global destruction (and thus circular references) include:

        During global destruction, proper order of destruction is not enforced, which can lead to an object being destroyed after an object that it depends on has already been destroyed. This can produce obnoxious warnings, increase the complexity of destruction code, or just make proper clean-up not reliably possible.

        It also means that a long-running process that ends up making multiple connections to a database (for example) will "leak memory" or even leak other resources (like hording open file handles).

        It can also delay or even prevent the flushing of data. It can also delay the detection and reporting of bugs like a user forgetting to "finish" some operation. In some environments, delaying such reporting until global destruction can easily effectively make such reporting useless.

        Did you demonstrate that my patch creates circular references?

        Do you have some alternate theory as to why destruction gets delayed until global destruction? The simple, obvious explanation is that the extra reference that your "fix" creates produces a cycle. I didn't provide detailed documentation of the exact nature of the cycle, but stuff not getting destroyed when everything related to it has gone out of scope is pretty convincing evidence of the cycle existing in this case.

        Are you implying that my method chaining and the resulting destruction was unsound?

        Rather than implying it, I thought I stated it quite explicitly:

        you should simply stop writing code that destroys the container object if you want to keep using one of the contained objects

        Yes, it is "unsound" to make the controller object a temporary throw-away that does not live long enough for you to finish using the subordinate object that you got from it (if the subordinate object's life cycle is supposed to be limited to within the controller's life cycle, as is the case here).

        - tye        

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://923403]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (5)
As of 2014-10-22 05:28 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (112 votes), past polls