Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2011-01

inheriting handles using TProcess in unix

8 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Seth Grover

http://www.freepascal.org/docs-html/fcl/process/tprocess.inherithandles.html says "On Unix, setting this variable has no effect." Why is this?

The reason I ask is that often when using TProcess I run into the problem where if I execute some script or program which perhaps forks and outlives my original fpc process that this new forked process inherits all of the open descriptors belonging to my original process, which is usually not what I want.

Normally I just take care of this in the child process by looping through all of the file descriptors greater than > 2 (stderr) and closing them. But it seems like in a more general sense this would be something that TProcess could do. I'm contemplating patching TProcess so that if FInheritHandles is false (default is true) it would do this.

Thoughts?

-SG

This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com

Reply by email

Unknown author
to Seth Grover
Seth Grover wrote 17 lines
http://www.freepascal.org/docs-html/fcl/process/tprocess.inherithandles.html says "On Unix, setting this variable has no effect." Why is this? The reason I ask is that often when using TProcess I run into the problem where if I execute some script or program which perhaps forks and outlives my original fpc process that this new forked process inherits all of the open descriptors belonging to my original process, which is usually not what I want. Normally I just take care of this in the child process by looping through all of the file descriptors greater than > 2 (stderr) and closing them. But it seems like in a more general sense this would be something that TProcess could do. I'm contemplating patching TProcess so that if FInheritHandles is false (default is true) it would do this. Thoughts?

By all means, go ahead. I didn't know there was a way to enumerate all file descriptors.

Michael.

Reply by email

Seth Grover
Show quoted text 10 lines
> I'm contemplating patching TProcess so that if FInheritHandles > is false (default is true) it would do this. > > Thoughts? By all means, go ahead. I didn't know there was a way to enumerate all file descriptors. Michael.

My current thought is to use FindFirst/FindNext in the context of the child process after the fork but before the exec to enumerate the contents of /proc/[pid]/fd/ and close all the descriptors greater than
2. I don't have experience in all different flavors of UNIX, but from what I've read procfs is standard in UNIX.

-SG

This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com

Reply by email

Marco van de Voort
to Seth Grover

In our previous episode, Seth Grover said:

Show quoted text 9 lines
> > Michael. > My current thought is to use FindFirst/FindNext in the context of the child process after the fork but before the exec to enumerate the contents of /proc/[pid]/fd/ and close all the descriptors greater than 2. I don't have experience in all different flavors of UNIX, but from what I've read procfs is standard in UNIX.

It is not in all flavours, and many BSDs can turn it off.

But that is more theoretical. The more practical problem is that while /proc might usually exist, its contents and permissions vary. (and that also goes for Linux, specially on embedded variants)

If this really is an huge problem, I would add the possibility to trigger an event on the moment this is required. This allows for system specific operations by users, without unnecessarily complicating TProcess (and differentiate its default functionality per target, leading to documentation, maintenance and support issues)

Reply by email

Henry Vermaak
to Seth Grover: http://www.freepascal.org/docs-html/fcl/process/tprocess.inherithandles.html says "On…
Seth Grover wrote 8 lines
http://www.freepascal.org/docs-html/fcl/process/tprocess.inherithandles.html says "On Unix, setting this variable has no effect." Why is this? The reason I ask is that often when using TProcess I run into the problem where if I execute some script or program which perhaps forks and outlives my original fpc process that this new forked process inherits all of the open descriptors belonging to my original process, which is usually not what I want.

You can prevent file descriptors from surviving an exec by setting the FD_CLOEXEC flag for that file descriptor with fcntl(). This is obviously not thread safe, so there is an O_CLOEXEC flag for open().

See here:

http://udrepper.livejournal.com/20407.html
http://www.gnu.org/software/libc/manual/html_node/Descriptor-Flags.html#Descriptor-Flags

Henry

Reply by email

Seth Grover
to Seth Grover: My current thought is to use FindFirst/FindNext in the context of the child process after…

Marco said:

Show quoted text 9 lines
It is not in all flavours, and many BSDs can turn it off. But that is more theoretical. The more practical problem is that while /proc might usually exist, its contents and permissions vary. (and that also goes for Linux, specially on embedded variants) If this really is an huge problem, I would add the possibility to trigger an event on the moment this is required. This allows for system specific operations by users, without unnecessarily complicating TProcess (and differentiate its default functionality per target, leading to documentation, maintenance and support issues)

Excellent idea. I've begun doing just as you suggested. Currently it seems to me that this would be an "{$ifdef UNIX}" thing only in process.pp. The reason I say this is that for the windows and wince implementations of process.inc I don't see a place this event could be triggered. The Windows API call CreateProcess is somewhat different then UNIX's model of fork then exec, in between which I can trigger the event so it happens in the context of the child process.

-SG

This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com

Reply by email