develooper Front page | perl.perl6.users | Postings from March 2021

Re: too many file handles

Thread Previous | Thread Next
Richard Hainsworth
March 17, 2021 21:02
Re: too many file handles
Message ID:
After working at this, I finally found where it was happening, and a 

I was checking all 517 http/s links in the documentation to see whether 
they are all live (not 404 and host found). For this I was using 

The relevant bits of code was something like

for @links -> $link { # @links.elems = 517

     my $http =;

     try { $rv = $http.HEAD($link).perform.response-code }

     if $! { $rv = $http.error }


I had assumed that as soon as the $http went out of scope, it would be 

When I rewrote as

my $http =;

for @links -> link { ... }

then the program ran to completion without failing with 'too many file 

Now my question is this: Is this a problem with the LibCurl::Easy 
module, where I can raise an issue.

Or is this a more general Raku problem with objects not being garbage 


On 17/03/2021 17:55, Elizabeth Mattijsen wrote:
>> On 17 Mar 2021, at 18:45, Richard Hainsworth <> wrote:
>> I have been running into this error: "Too many open files"
>> Sorry for the lack of detail. The problem is that the error comes up in odd places, so I have found it difficult to golf down into Raku program that always fails with this error.
>> When I separate out the code that leads to the error, and create another program, Raku handles it without difficulty. It seems to occur when there are a lot of moving parts, so to speak.
>> I am not explicitly opening file handles, but the software I have written is using the idiom
>> "some-filename.html".IO.spurt( $an-accumulated-string );
>> Obviously, filehandles are being opened under the hood. Having written a file, there is no need to reference it again, so I could close the filehandle.
>> I have been told that because of the way garbage handling is implemented, there is a problem with file handles.
> That's should only happen if you specifically open a file to obtain an IO::Handle: if you don't close it yourself (e.g. via a LEAVE block like: LEAVE .close with $handle), *then* you run this risk, as the IO::Handle.DESTROY method *will* close the handle, but you cannot be sure as to when IO::Handle.DESTROY gets called.
>> If so, what is a safer idiom to use in place of and IO on a string, so that the handle can be closed immediately after use?
> The "filelame".IO.spurt($string)" is the exact idiom to ensure that file handles are getting closed for you automatically.  And I've just checked the code: the OS file handle *is* specifically getting closed with an nqp::closefh($!PIO).  Specifically, the sequence is:
>      my $PIO := nqp::open($path,$mode);
>      nqp::writefh($PIO,nqp::decont(data));
>      nqp::closefh($PIO);
> Now, you can't get more succinct than that: it doesn't even open an IO::Handle at all!
> The only thing I can think of at this moment, is that somehow nqp::closefh() is leaking?  Perhaps creating an issue for this, is in order!
> Liz

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About