On Thursday, January 3, 2002, at 02:02 PM, Jeffrey W. Baker wrote: > This seems like a really weird problem. The Store module is destroyed > while another module still has a reference to it. Unfortunately for you > and I, the only conclusion I have been able to draw is that Perl's > DESTROY > magic is unreliable. We have modules in my company where things are > randomly undefined in DESTROY subroutines, because the DESTROY of the > referenced thing has already been called. So, somewhere in Perl there > is > a bug, possibly an off-by-one in the reference counting.
It's probably not the reference counting, since the global destruction phase uses a mark-and-sweep system rather than refcounts (and that's where my knowledge ends). I think that the order of global object destruction is totally random, whereas refcount destruction is predictable. After searching p5p, this seems to be known and accepted behavior. I suppose there could be a refcount bug that's causing %session not to be cleaned up until global destruction. > Anyway you can work around it. Explicitly call tied(%session)->save() > when the time is right. True, I guess I'll do that, but I'd like to figure out a little more about it too. -Ken
