Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • And global destruction's unordered, which is likely where your problem lies. When your program ends, perl just sweeps through all the oustanding live objects with destructors in pretty much a first-to-last order. (First to last in memory at least. This is not necessarily chronological order, nor will it necessarily be the same order from run to run of your program, depending on what its doing)

    The only safe way to handle things here is make sure that your objects die before global destruction.
    • So, in your example code, if you wrapped a block around everything from the "my $session = ..." to the "#undef ...", then the session would be closed properly when the block was exitted, but since you just "fall off the end" the remaining stuff gets discarded in arbitrary order. You would also have te same problem, I think, if you terminated with an explicit exit statement - so, as well as wrapping your mainline inside a block you could put a label (say EXIT:) on the block and change any exit statements an
    • Thanks for the response. What you describe is exactly what I have concluded is happening, I just didn't think it was supposed to happen that way.

      And global destruction's unordered, which is likely where your problem lies.

      Do you have a reference for this? I've looked and can't find a thing about it.

      I did find this in Programming Perl, 3rd Edition (page 331)

      When an interpreter shuts down, all its objects are destroyed, which is important for multithreaded or embedded Perl applications. Objects are alway

      • I found someone else mentioning [thepen.com]the fact that global destruction is unordered.
      • As I recall (from a long time ago), it is impossible to ensure a good ordering using just ref counts because it is easy to have reference loops (e.g. two objects each with a reference to the other or an object that has a reference to itself, or a list of things that links back to the "beginning" of the list). So, since most programs don't care about the order anyhow and the ones that do can arrange things for themselves, there was no point in spending any time to do a half-hearted ordering.