Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re^2: Catching errors in closing lexical filehandles

by gaal (Parson)
on Sep 27, 2004 at 09:36 UTC ( #394108=note: print w/replies, xml ) Need Help??


in reply to Re: Catching errors in closing lexical filehandles
in thread Catching errors in closing lexical filehandles

Good stuff, thanks for the link.

I for one wish Perl6 will have some way of requesting timely destroyed objects. :)

  • Comment on Re^2: Catching errors in closing lexical filehandles

Replies are listed 'Best First'.
Re^3: Catching errors in closing lexical filehandles
by dragonchild (Archbishop) on Sep 27, 2004 at 12:29 UTC
    Would it be enough that all items who wish to be notified of the destruction are notified in a timely fashion? This would be vs. at the time of the actual freeing of the memory, which the DOD run is needed for.

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

    I shouldn't have to say this, but any code, unless otherwise stated, is untested

      I think so! Not speaking as an expert here, but as a programming language user: once a variable goes out of scope, it is effectively out of the game. If going out of scope frees memory, wonderful. If it does other useful things like close files as well, wonderfuller. And if it does this at the best likely time, wonderfullest :)
        Not to lessen your sense of wonderfulness, but there are problems with both true GC and reference counting.

        With true GC, variables going out of scope will eventually be freed. Open filehandles will be closed. etc. However when that will happen is another story. This is an issue when you're using some form of scarce resource.

        For instance the fact that some of your open filehandles will be closed someday does not help you if you've run over the local OS limit for open filehandles right now. Likewise leaking statement handles might make your database very unhappy. These are downsides to true GC.

        On the other hand reference counting isn't perfect either. First there is the obvious deficiency - circular references never go away. However there is also the hidden problem that it takes a lot of code distributed throughout your codebase to keep reference counts correct - and problems in that code are not that obvious. (Well, not if the bug is to add an extra 1 to the reference count...) This means that using reference counting increases the number of bugs in Perl.

        The upshot is that with true GC you want to close external resources yourself - because eventually may not come soon enough. With reference counting you have reliable timing, but it is really hard (read next to impossible) to get the implementation right.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (5)
As of 2020-06-06 21:44 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Do you really want to know if there is extraterrestrial life?



    Results (41 votes). Check out past polls.

    Notices?