Beefy Boxes and Bandwidth Generously Provided by pair Networks
Come for the quick hacks, stay for the epiphanies.
 
PerlMonks  

Re: Track open file handles

by Eily (Monsignor)
on Apr 05, 2017 at 15:40 UTC ( [id://1187143]=note: print w/replies, xml ) Need Help??


in reply to Track open file handles

id_2obj returns undef when I try open with a glob or a bareword rather than a scalar, id_obj($_) // $_ fixed that.

I don't get the point of using Hash::Util::FieldHash and id_2obj though, since creating the anonymous returned by get_fds will only keep the stringified version of the object. Not having a Hash::Util::FieldHash hash, and not calling id_2obj gives the same result.

I thought it would be a good idea to do all the work (fill the hash) in $open and $close, and then goto those functions rather than call them, to remove the extra stack entry. This would have made your module transparent when using autodie and a verbose Carp (autodie croaks). But your $open and $close subs are bypassed anywhere autodie is on. It does work again when lexically disabling autodie with no autodie;

Replies are listed 'Best First'.
Re^2: Track open file handles
by shmem (Chancellor) on Apr 05, 2017 at 16:30 UTC
    I don't get the point of using Hash::Util::FieldHash and id_2obj though, since creating the anonymous returned by get_fds will only keep the stringified version of the object.

    The point of using Hash::Util::FieldHash is that the key/value pair in a fieldhash gets automatically deallocated when its underlying object gets out of scope or is destroyed. If I would use a normal hash, and would be allocating at open, deallocating at close, I would not have the filehandles which have been successfully opened and closed and gone out of scope but not been destroyed, because there is a dangling reference to them.

    The stringified filehandle object... well, that is due to indecision. If the anonymous hash returned by get_fds would sport the filehandle objects themselves, their reference count would be increased. If that returned result is not deallocated, further leakage would ensue, which would counter the whole purpose of that module. OTOH, getting a list of open filehandles for subsequent close would be a nice thing, too.

    Fix for the bareword issue (also for open *STDERR etc):

    *CORE::GLOBAL::open = sub { my $result = $open->(@_); my $ref = ref $_[0] ? $_[0] : *{$_[0]}{GLOB}; if ($result) { $fd{$ref}->{open} = join " ",@_,caller; $fd{$ref}->{opentime} = join ".", gettimeofday; } $result; }; *CORE::GLOBAL::close = sub { my $result = $close->(@_); my $ref = ref $_[0] ? $_[0] : *{$_[0]}{GLOB}; $fd{$ref}->{close} = join " ", caller; if ($result) { $fd{$ref}->{close} .= " (closed)"; } else { $fd{$ref}->{close} .= " (close failed)"; } $fd{$ref}->{closetime} = join ".", gettimeofday; $result; };

    update: alternative class method/function get_fds:

    sub get_fds { return { map { my $fd = id_2obj $_; $fd => { fd => $fd, %{$fd{$_}} } } keys %fd }; }
    perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

      Without Hash::Util::FieldHash, no reference to the filehandle is kept anywhere (since the hash would only keep a stringified version), so there's nothing preventing it from being destroyed. But it does make sense to stop tracking a filehandle if it can't be accessed anywhere because the variables holding are all out of scope.

      I think returning the filehandle is a good idea, although it can be used for cleanup, it should only be a temporary solution until the real issue with the code is fixed. And if someone trying to fix their code just keeps collecting references to their handles without releasing them, the problem probably is not with your module in the first place. Maybe you can keep a weakened reference to the handle though, that way unless the user keeps a copy of that reference, you have access to the handle, without preventing its deletion.

        Without Hash::Util::FieldHash, no reference to the filehandle is kept anywhere (since the hash would only keep a stringified version)

        But this stringified key / value pair would not be destroyed if its object goes out of scope. It is just that what Hash::Util::FieldHash does for me - the housekeeping. Why shouldn't I use it?

        I think returning the filehandle is a good idea ... Maybe you can keep a weakened reference to the handle though

        Again, that is what Hash::Util::FieldHash does for me. It keeps a weakened reference and uses the decimal value of the adress part (0xdeadbeef) as key into the fieldhash. The weakened reference has magic attached which provides for deletion of the hash entry when it's freed.

        But! returning a weakened reference from get_fds is a good idea. Thank you.

        perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others cooling their heels in the Monastery: (5)
As of 2024-04-26 08:37 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found