in reply to Re^5: Forks, Pipes and Exec (file descriptors)
in thread Forks, Pipes and Exec
I can make a change in the parent to STDOUT that affects the child's STDOUT.
It depends what change you are making and how you are perceiving that the the child has been affected.
In general, I do not consider Perl's Win32 fork emulation worth the effort of bothering with. There are simply too many differences between the platforms and holes in the emulation, that make *nix techniques fail to work. A few examples:
- In your snippet above, you create a pipe and set it up as stdout and then you attempt to set it non-blocking, presumably with the intent of use select upon it.
But win32 anonymous pipes cannot be set non-blocking and so cannot be used in conjunction with select.
Note:Win32 pipes can be used in a non-blocking fashion--using peeking (polling) or asynchronous IO or overlapped IO, but none of these fit well with the select mode of operations. This is not a limitation, but rather a difference in design philosophy that is hard to reconcile in a portable fashion.
- If you do a fork followed by exec on *nix, then the pid returned to the 'parent' is process handle to the newly started process.
If you do the same thing using the win32 emulation, the 'pid' is actually a disguised thread handle to a thread, and the process you "exec'd" is actually started as an entirely new process (using what is effectively the same as system), with an entirely different pid to that returned by fork--and to which you can never get access.
Consequently, anything the parent does with that pseudo-pid only affects the thread--not the "exec'd" process. Eg. killing the pseudo-pid (or attempting send almost any signal) will terminate the thread, but leave the process running.
Again, it is perfectly possible to set up bi-directional communications between a parent and child process under win32 at the C-level, but far harder to see how to make this available to Perl programs ina platform agnostic way.
- Signals are not implemented (by the system) on win32, and only a handful (2,3,15,21) are emulated in a way that can be trapped.
That means you will never receive a SIGCHLD in the parent. Whilst wait and waitpid are emulated, it is done by having the child thread block in a system wait on the child process, which makes for very different and confusing semantics.
Those are just a few of the limitations that come to mind. I've encountered several more anomalies that don't. IMO these difference make trying to code portable programs using fork unworkable if win32 is a target platform.
If you application calls for single direction piping of data to or from the child, then using the forked-open is effective and far more portable. If you bi-directional communications between parent and child, then threads can provide an effective solution that is again, far more portable than fork.
Your question to date simply asks about forking and pipes ,without giving any hint as to the actual application, so it is impossible to suggest alternatives to that approach.