Re^3: pipe fork win32
by Marshall (Canon) on Aug 26, 2012 at 08:28 UTC
|
I re-booted my machine and I ran your code and it did work!
The sleep(1) in the client is what I tried before and it did not work. I think that there are some flaky things having to do with Win XP. After a re-boot this worked. I am completely flabbergasted why it did not work before.
| [reply] [Watch: Dir/Any] [d/l] |
|
Hej Marshall,
I had similar experiences a year ago with the emulation of fork in Windows (Windows 7 Home Premium with Service Pack 1).
Running the tests of Test::TCP (version 1.11 and 1.12) on Windows resulted often in a blocking Perl interpreter. Sometimes the system reached at state, that it must be restarted.
I started trying to isolate the problem and this is so far I came: https://rt.cpan.org/Public/Bug/Display.html?id=66016#txn-910155.
My experiences/conclusion using perlfork - Perl's fork() emulation in Windows, are:
-
There is stochastic involved. Two identical calls (expected to give the same result) can give different results. What I understand is the problem in the implementation of the Windows API and not in the Perl implementation.
-
In some cases the processes running the Perl interpreter are blocking (coming in an unwanted state).
-
Sometimes the problem is not solved by restarting the Perl interpreter. Is there some missing initializations in the Perl interpreter?
-
In some rare situations the total system (not just the process running the Perl interpreter) is affected, and must be restarted. Sometimes it even must be restated using power down/up. The isolation between processes and the operating system in Windows has some weakness?
The questions which worries me are:
-
Is it advisable to use the Perl's fork() emulation in Windows in “production” code?
-
Is it enough to run the test of Perl modules just once or how many times are they needed to be run?
| [reply] [Watch: Dir/Any] |
|
Fork in general is fine, although most/all CPAN modules will leak resources with fork unless they specifically say they are psuedo fork safe (have a CLONE method or use mg_dup magic). Doing a kill on a child absolutely isn't safe and never will be completely safe see ( https://rt.perl.org/rt3/Ticket/Display.html?id=88840 ). Previously doing a kill on the child the moment the parent starts the child (why would you do that in production code?) would hang the parent interp later in the parent interp's execution. I am not doing a kill anywhere. I need to, and have the child exiting voluntarily.
| [reply] [Watch: Dir/Any] |
|
Is it advisable to use the Perl's fork() emulation in Windows in “production” code?
Personally, I'd say that you should not use Perl's Win32 fork emulation at all.
This not necessarily because of bugs in that implementation -- though I have no doubts they exist -- but because
- that emulation is not complete enough to allow *nix programming paradigms to be ported to windows without changes
- its actual behavior isn't well-enough (at all?) documented to allow for a set of rules to be written down about what will and won't work.
As is, the fork emulation creates expectations of portability that are simply not achievable. Better I think to simple say "do not use".
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
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.
RIP Neil Armstrong
| [reply] [Watch: Dir/Any] |
|
Is it advisable to use the Perl's fork() emulation in Windows in “production” code?
Windows just doesn't do "fork" very well. Threads are the way to go with Windows, but that model is more complex. BrowserUK knows a lot about how to do this on Windows. I would say that emulate behavior X on Y, often doesn't work out that well.
| [reply] [Watch: Dir/Any] |
|
I am completely flabbergasted why it did not work before.
Yeah! Me too.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
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.
RIP Neil Armstrong
| [reply] [Watch: Dir/Any] |
|
I previously had been working on recovering data from a damaged SD card. I managed to get 1,500+ files off of this thing. But Windows was not "happy" and I had to re-boot many, many times during this process. I also do not know how, but there do appear to be some kinds of errors that can mess Windows XP up in weird ways. I do not know why.
| [reply] [Watch: Dir/Any] |
Re^3: pipe fork win32
by bulk88 (Priest) on Aug 26, 2012 at 12:34 UTC
|
Perl sleep on windows in a VM or 100% CPU usage or C debugger breakpoints, or bad driver that likes lock all the CPUs and then spin sleep for too long to freeze the PC can cause an overflow in Perl's sleep, and then only a random Windows message (mouse move, repaint, idk what else, but there WILL be one, thx MS) will breakout of the sleep hang, see https://rt.perl.org/rt3/Ticket/Display.html?id=33096 causing the sleep to take more seconds than it should have. win32/win32.c#l2163 in perl.git for the offending code. | [reply] [Watch: Dir/Any] |
|
Firstly, this perl-internals implementation bug is totally unrelated to the issue of whether "sleep work on multiple threads".
Secondly, the "bug" in that RT isn't a bug.
It basically says that sleep doesn't guarantee to return exactly when you asked for it to. But I'm not aware of any OS that gives such a guarantee, It is documented to sleep for at least the number of seconds requested.
It does not say that it will break out of a broken device driver, or debugger, nor VM, nor preempt a higher priority CPU-intensive thread or process.
I'm really confused why you thought it was relevant to raise that non-related, non-issue in this context?
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
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.
RIP Neil Armstrong
| [reply] [Watch: Dir/Any] |
|
# Failed test 4 - right time (waited 1 secs for 3-sec alarm) at op/
+alarm.t line 55
op/alarm.t...........
Failed 1/5 subtests
# Failed test 2 - right time (waited 5 secs for 3-sec alarm) at op/
+alarm.t line 35
op/alarm.t ........................................................
Failed 1/5 subtests
And that system has been having a randomly failing alarm.t since, forever I think.
If a GUI program that is not doing anything CPU or I/O intensive randomly stops responding to mouse movement for 4 seconds, it would be completely unacceptable. Clearly the OS manufacturer (Microsoft) did not design the OS to ever do that, so other app specific causes should be considered. I couldn't tell whether Marshall's scripts output was done with his ping backticks delay or whether with a sleep(), I assumed sleep() since he claimed he rebooted and sleep() starting working accurately again. | [reply] [Watch: Dir/Any] [d/l] [select] |
|