Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Re^3: Threads and signals in Windows

by BrowserUk (Patriarch)
on Mar 09, 2013 at 16:37 UTC ( [id://1022591]=note: print w/replies, xml ) Need Help??


in reply to Re^2: Threads and signals in Windows
in thread Threads and signals in Windows

One example of stochastic behavior...

You reinvented a fork bomb. Except on windows, fork actually spawns a thread; so it might better be termed a thread-bomb in this case.

Try feeding this:  :(){ :|:& };: to bash on a *nix system and see how deterministic the DoS is.

You are also asking the child 'process' to kill its parent 'process'; but on windows they are actually just threads within the same process. Ie. You are attempting to kill your own process. In addition, you are also thread-bombing the system from within that same process. Is there any wonder that the process may not respond to the request in a predictable manner?

And you are using a random delay -- sleep 0 equates to "relinquish the rest of the current timeslice" which is an unknowable quantum of time, that could range from 0 microseconds -- if the timeslice was about to end anyway; or if there are no other processes in the system immediately eligible to run -- to N * q where N is the number of other processes and threads in the system that are eligible to run; and q is the scheduler quantum which can vary from ~5 to ~180 microseconds depending upon: a) the version of Windows; b) how that version is configured (workstation or server; foreground or background priority); c) a whole bunch of other factors.

In other words; you have programmed a random delay into your program as surely as if you had written Win32::Sleep( rand()*100 ).

Of course the behaviour is "stochastic"; That's how you programmed it to be!

Could you accept (or even recommend) the addition of something like this:

Neither!

I use kill (on windows) to good effect all the time. The difference is that I have spent enough time to understand the limitations of the emulation on my platform. I understand that they give me a fairly crude interface to the native Console control handler functionality from Perl; and that -- used carefully -- can provide functionality that I might otherwise have to dip into Inline::C or XS to gain access to.

What I would say; and have said many times; is do not attempt to use fork & the windows signals emulation to try to port *nix idioms to windows; because you will be sadly let down.

The basic problem here is the entire attempt to make Windows look like or work like some variant of *nix. It is simply far easier to write two scripts -- one for each platform -- than to try and construct and maintain one that will operate correctly on both platforms.


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.

Replies are listed 'Best First'.
Re^4: Threads and signals in Windows
by bojinlund (Monsignor) on Mar 10, 2013 at 07:01 UTC

    BrowserUk, thank you!

    What I would say; and have said many times; is do not attempt to use fork & the windows signals emulation to try to port *nix idioms to windows; because you will be sadly let down.

    Based on this, I will propose an addition to the documentation of function fork (and perhaps also kill) in the Perl Language reference.

    You reinvented ... a thread-bomb.

    And you are using a random delay -- sleep 0 equates to "relinquish the rest of the current timeslice" which is an unknowable quantum of time, that could range from 0 microseconds

    My “thread-bomb” resulted in a patch. The patch http://perl5.git.perl.org/perl.git/commitdiff/82e24582 adds to t/op/fork.t:

    +system $^X, "-e", "if (\$pid=fork){sleep 1;kill(9, \$pid)} else {sle +ep 5}";

    Is this also a thread-bomb, or is it OK with non zero sleep?

    The patch also changes win32/win32.c:

    --- a/win32/win32.c +++ b/win32/win32.c @@ -1282,6 +1282,13 @@ win32_kill(int pid, int sig) case 9: /* kill -9 style un-graceful exit */ if (TerminateThread(hProcess, sig)) { + /* Allow the scheduler to finish cleaning up the +other thread. + * Otherwise, if we ExitProcess() before another +context switch + * happens we will end up with a process exit cod +e of "sig" instead + * of our own exit status. + * See also: https://rt.cpan.org/Ticket/Display.h +tml?id=66016#txn-908976 + */ + Sleep(0); remove_dead_pseudo_process(child); return 0; }

    Is it OK with “Sleep(0)”, or must it be a non zero parameter value? Can the non zero time value cause that we still sometimes get 9 as an erroneous exit value? What is the smallest non-zero value that can be used?

      Is it OK with “Sleep(0)”, or must it be a non zero parameter value?

      The problem here is the assumption that yielding the processor will ensure that the terminated thread has had time to fully clean up before this thread will get another timeslice and exit. If the system is busy, many other threads in the system are eligible to run -- especially if they are higher priority -- then the callee of TerminateThread() might easily get several timeslices before the thread actually ends.

      The correct (or maybe just better) thing to do, would be to pass a known exit code value on the TerminateThread() call and then loop checking the thread exit code until it returns that value rather than STILL_ACTIVE. Eg. Something like this:

      TerminateThread( hProcess, 123456789 ); Sleep( 0 ); GetExitCodeThread( hProcess, &exitCode ); while( exitCode != 123456789 ) { Sleep(0); GetExitCodeThread( hProcess, &exitCode ); }

      Once GetExitCodeThread() returns the known value, you should be pretty certain that the thread has actually terminated.


      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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1022591]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (6)
As of 2024-03-19 14:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found