Open taboege opened 6 years ago
I revert commit 21b30354731f83924813b2792cc2e2db15568de7 to let GC work (my fault) in https://github.com/wukgdu/p6-File-Temp, and add words in readme and test about closing fh for Windows (opened files could not be unlinked on Windows).
Somewhat related, my understanding is that the role File::Temp::AutoUnlink is completely useless at the moment, because %roster and %keptfd prevent the GC from collecting handles which are actually not used anymore. Correct?
Things about DESTROY
are not changed.
I have a long-lived process which polls a web resource using the WWW module. WWW uses a fresh HTTP::UserAgent for every request, which in turn uses File::Temp for its cookie file. Since the process doesn't terminate soon, I get a lot of unused cookie files cluttering my /tmp and, which is worse, my process quickly runs out of file descriptors.
Now, there are three modules at play here. My current workaround is to ditch WWW and directly use a single HTTP::UserAgent, with a single
tempfile
. An argument could be made that HTTP::UserAgent should tidy up its cookie file if it's a temporary one, but the interface of File::Temp kind of promises to take care of that. I think File::Temp shouldn't uncontrollably hold onto every file it creates.I'm not sure what should be done about this, though. Reading IO::Handle.close and the discussion about DESTROY in #18, which was quite some time ago, it seems that you can't reliably offer the
:unlink
adverb without using END, which forces you to keep track of all temporary files?Somewhat related, my understanding is that the
role File::Temp::AutoUnlink
is completely useless at the moment, because%roster
and%keptfd
prevent the GC from collecting handles which are actually not used anymore. Correct? While DESTROY is not reliable for resource management, it would have provided a relief for my particular (long-running) case here.