Re: Conduit missing closing file handles
Tom Ellis <[email protected]> Fri, 1 May 2026 13:57:44 +0100
| Newsgroups | gmane.comp.lang.haskell.cafe |
|---|---|
| Message-ID | <afSjSGqF_xlUKZjW@cloudinit-builder> |
On Fri, May 01, 2026 at 11:26:34AM +0200, Henning Thielemann wrote: > On Thu, 30 Apr 2026, Tom Ellis wrote: > > You have to be a bit careful about what "immediately after reading" > > means. Actually, I think it means "immediately after the file handle > > indicates it has reached end of file". > > Interesting. This would explain my observations. But if the file handle is > not closed immediately, this Conduit is not much better than lazy readFile, > is it? In this case `conduit` is no better than lazy readFile. Unfortunately I think the approaches to streaming effects in `conduit`, `pipes` and `streaming` which build effects out of data (which I call the "synthetic" approach to effects) is doomed with regard to resource safety. In fact I'm astonished they persisted so long. Bluefin been a direct wrapper of `IO` (what I call an "analytic" approach to effects) has no such problems, however. (I don't know about `streamly`. I haven't looked at it and I understand it takes a somewhat different approach.) > > However, there is sadly not a large ecosystem around Bluefin, and no Zip > > library. > > My program would also require a Tar library. Can you please try this Bluefin version of convertZipToTar and confirm whether it does what you want without leaking handles? https://github.com/tomjaguarpaw/ad/blob/master/BluefinZipTar/BluefinZipTar.hs#L43-L65 If so I can tidy up the library and publish it as something minimally usable. Tom _______________________________________________ Haskell-Cafe mailing list -- [email protected] To (un)subscribe, modify options or view archives go to: Only members subscribed via the mailman list are allowed to post.