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.