Use of O_CLOEXEC is not BSD friendly

[xtophe]

It is Linux specific (was introduced in 2.6.23 according to the man page)

It is introduced by [b4d4f2b856cd0d5e24f777a]

[lennart]

Provide a patch! Portability to non-Linux OSes depends on external contributor patches!

[hrickards]

A fix to this bug quite soon would be useful as it's currently holding back lives (a popular video editing program) from being built on kfreebsd and hurd on Debian. Although this can be fixed in the next lives upload to Debian by not Build-Depending on libpulse-dev and Depending on libpulse0, it would be better if this were fixed upstream in pulseaudio.

[lennart]

Hehe, I am sorry, but portability to OSes like Hurd or some BSD is not a priority for me at all. I won't make portability to those OSes particularly hard, but I won't prepare the necessary patches for you either. If you want anything done in this area, then please provide a patch. Otherwise this will not be fixed anytime soon.

[sjoerd]

proposed patch

[matthijs]

This does not affect just BSD, also older Linux systems (< 2.6.23) break on this (I've come across this bug when compiling Pulse for OpenWRT).

As for the patch, it looks like an elegant solution to solve the problem. If there is such a pa_make_fd_cloexec function, is there any reason it's not used in src/pulsecore/database-tdb? There, the O_CLOEXEC flag is just left out if it's not supported.

[lennart]

Replying to matthijs:

This does not affect just BSD, also older Linux systems (< 2.6.23) break on this (I've come across this bug when compiling Pulse for OpenWRT).

I am not too concerned about older Linux kernels. Due to the general buginess of the various audio drivers in the older Linux kernels, running PA on them is not a lot of fun anyway (unless you set tsched=0).

As for the patch, it looks like an elegant solution to solve the problem. If there is such a pa_make_fd_cloexec function, is there any reason it's not used in src/pulsecore/database-tdb? There, the O_CLOEXEC flag is just left out if it's not supported.

Generally we should use O_CLOEXEC everywhere insead of depending on pa_make_fd_cloexec(), since it fixes a couple of races.

[lennart]

And the patch proposed does not fully solve the problem unfortunately. If you have a new glibc on an old kernel you'll get EINVAL or so when using O_CLOEXEC.

I think the proper fix would be to introduce pa_open_cloexec() or so that abstracts the handling of O_CLOEXEC. I'll start working on that.

[lennart]

Version in git now uses pa_open_cloexec() everywhere which properly checks for O_CLOEXEC to be available.