[Haskell-cafe] Discussion: The CLOEXEC problem

[Donn Cave]

Quoth David Turner <dave.c.turner at gmail.com>,
> Could you be a bit more specific? Which bits of pre-existing software
> didn't have a FD_CLOEXEC bit and would be broken by this proposal?

Well, of course to be precise, the bit's always there, it's just
normally not set - that's the normal environment that anything
written up to now would expect.  And of course, anything that depends
on a GHC-opened file to stay open over an exec would be broken.
I can't enumerate the software that meets that criterion.

> Since Python recently decided to go through this exact transition, their
> experience should be instructive. Do you know if there was negative fallout
> from PEP 0466?

I gave up on Python a long time ago and don't follow what goes on.
If recently means less than a decade or so, though, it's not much to
go on.  If the problem addressed by the O_CLOEXEC proposal is obscure,
the problems it may create are even more so - I'll certainly concede
that - and it could take a lot of experience before those problems
would be well known enough to show up if you went looking for them.

> When thinking about FDs from outside the Haskell runtime (whether inherited
> or simply opened in an external library), can you give an example of a case
> where such a FD causes a problem if inherited and yet cannot be set as
> FD_CLOEXEC at source?

Sorry, I'm confused here.  Files opened within GHC and externally have
equal potential to work as intended or to cause problems, it seems to me.
If we infer from the proposal that GHC-opened files with CLOEXEC unset
may cause a problem, then it follows that other files with CLOEXEC unset
also may cause the same problem.  The proposal addresses only the former,
and not the latter, and only for normal files - while the ordinary solution,
as implemented in UNIX popen(3), deals with all - pipes, sockets, etc.

	Donn