Fds accessor

[cgull]

We're using pstreams in a threaded program and running into problems that can be solved with FD_CLOEXEC. We can get at the FILE*s with fopen() and then the file descriptors with fileno(FILE*). But this invokes unnecessary action, and our platform doesn't have an fdclose() call to clean up.

So I wrote a fds() accessor that returns the existing file descriptors, rather than new stdio files. This arguably is a better way to provide access to the underlying pipes, because it is easy to call fdopen() on these file descriptors.

Would you consider this? I left the code outside REDI_EVISCERATE_PSTREAMS because the interaction with raw I/O is simpler, and setsockopt/ioctl are valid, non-hacky reasons to access the file descriptors, but that is really your call. There's a couple of other small fixes as well. Tested on Ubuntu 17.04, OS X/Xcode 10.13, FreeBSD 11.1.

I've submitted this here because I don't have an SF account handy and GH is superior for submitting multiple commits, but I can submit on SF if that's better for you.

[jwakely]

Submitting it here is fine - makes it easier for me to fetch the change and merge it locally.

I haven't looked at the patch but it sounds sane, I'll take a proper look ASAP. Thanks.

[jwakely]

Sigh, this is a stupid warning from Clang. The code is fine. I'll merge this though, just to shut the warning up.

[cgull]

Over the weekend I realized that the better way to handle our problem would be to open all the pipes with O_CLOEXEC in the first place, and then reset that flag appropriately before executing the pipe child. Unfortunately, there's no portable way to do that: pipe() does not have a flags parameter, and so this would require the non-standard pipe2(), or maybe sockets, or named pipes, or something.

That however would be a more drastic change for a portable header-only library-- it would probably require using autoconf or nasty #ifdefs or something.

Our case is adequately handled by adding a little locking and setting FD_CLOEXEC later, so I'm not asking for anything-- just mentioning this issue for future reference.

[jwakely]

I know I've considered this problem in the past (many years ago), but I don't remember if I came to any conclusion. One option would be additional flags passed to the constructors and open functions that would set the close-on-exec flag.

(My long-term plan has always been to separate the creation of the child process and pipes into a separate process-management class, which would explicitly support such things, and then build the streambuf functionality around that ... but it's currently vapourware).

[cgull]

ping

I haven't seen anything for a while...

[cgull]

ping again...

Would it be better to submit this on SF?

[cgull]

rebased and cleaned up.

[jwakely]

Hi - no, I actually prefer using GH to SF, so this is fine, I'm just really bad at getting through my TODO list.

I'll re-review this tomorrow. Thanks for the ping.

[jwakely]

Why does the new function return a size_t and not a pmode ?

Other than that, it looks fine.

[cgull]

I don't know why it's size_t, my best guess is that I originally had it returning a count of file descriptors. I agree it should be pmode.