pstreams
pstreams copied to clipboard
jwakely
Fds accessor
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.
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.
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.
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).
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.
Why does the new function return a size_t and not a pmode ?
Other than that, it looks fine.
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.