|
in reply to Re: Win32, fork and XS globals
in thread Win32, fork and XS globals
As you know, on Windows, forking is emulated using a thread
I had read that, though I'm not really "up to speed" when it comes to "forking" or "threads".
Having spent my spare (sparse) moments over the last week or so trying to learn a little about this, I now find myself thinking "Wouldn't it make more sense to have emulated forking by using system() ?"
I'm thinking that way because it seems to me that system('perl -e "..."') comes closer to the *nix fork() than anything else.
Needless to say ... I stand to be corrected :-)
Cheers,
Rob |
Re^3: Win32, fork and XS globals
by Corion (Patriarch) on Oct 11, 2011 at 13:52 UTC
|
When using system() there remains the small problem of copying the state of the old process over into the new process. Especially copying over allocated external resources, like sockets and open file handles.
Of course, not copying has its problems too, if one part of the fork closes/deallocates a resource while the other part wants to keep it open. But I think the other direction is more common, that only one of the two forked instances will continue to access a resource. From that direction, using OS threads to emulate fork() makes sense.
| [reply]
[d/l]
[select] |
Re^3: Win32, fork and XS globals
by BrowserUk (Patriarch) on Oct 11, 2011 at 17:17 UTC
|
For a very large proportion of uses of fork -- essentially all those using the 'fork & exec' idiom -- system, especially system 1, ... is a far more effective 'emulation'. The spawned process can (by default does) inherit many of the system resources -- open file, pipe and socket handles and the like -- that forked processes inherit under *nix.
But, as Corion correctly points out, there are limitations that prevent it from being a transparent solution to porting forking programs to Windows.
It is possible to provide a more realistic and efficient fork emulation on Windows -- one that uses real processes and even COW memory. Creating the new process and giving it COW access to the parents memory segments is relatively trivial. The difficult part is fixing up the perl internals within the spawned copy.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l] |
|
|
But, as Corion correctly points out, there are limitations that prevent it from being a transparent solution to porting forking programs to Windows
Yep - thanks Corion, Buk.
By way of belated (and incomplete) explanation, I was led down this path by a PDL::Graphics::PLplot test script which does a couple of forks.
That test script works fine on nix systems, but exhibits some odd behaviour and errors on Windows. Thing is, of course, that the plplot library sets some globals and is not thread safe - not an issue with fork() on nix, but, as I've finally managed to grasp, prone to error with fork() on windows ... simple as that !!
Cheers,
Rob
| [reply] |
|
|
prone to error with fork() on windows ... simple as that !!
Indeed. I wish there was some way to estimate how many few instances of *nix forking code that work under Windows thanks to despite the fork emulation.
It might then be possible to argue for its removal and that could only benefit threaded code, that is currently hamstrung by 'features' necessary for that emulation.
It's way too late for that of course, but...
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
