http://qs1969.pair.com?node_id=1187157


in reply to Re: Track open file handles
in thread Track open file handles

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'

Replies are listed 'Best First'.
Re^3: Track open file handles
by Eily (Monsignor) on Apr 06, 2017 at 08:19 UTC

    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'
        Why shouldn't I use it?

        You should, I misread your answer actually (I thought you said the hash would prevent the deletion of the handles), I agree with you that this feature is useful.

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

        Adding it at the last moment, or storing it as a member as soon as the handle is opened (even if that means having two weak reference to the same handle in nearly the same place) is pretty much the same thing. There's a difference when you return $fd => { fd => $fd, %{$fd{$_}} } rather than id_2obj($_) => $fd{$_} though, in the first case, if the user keeps the hashref, it will always have the values it had when acquired, while in the latter, the "close" and "closetime" value will appear when the handle is closed. I like the first version better, because you have to call get_fds to get up-to-date information.