MPQC has asked for the wisdom of the Perl Monks concerning the following question:

Basically, here's what I've got so far. I've got a perl script which will be run remotely, by many networked computers simultaneously (dozen+). I've been testing the script to verify that it works - and it works great, at least for one computer. I haven't tested multiple computers as I don't have them available to me as of right now (and since it's a race condition, even if I run the tests it may not even show up). So, what I'd like to know is if running the following code would have the possibility of a race condition (send the keys to the wrong window):

... (unnecessary code) my @windows = FindWindowLike(0, "$uniquename", ""); for (@windows) { SetForegroundWindow($_); SendKeys("^{CAPS}"); } ... (unnnecessary code)

Each window being tested will have a unique name, so FindWindowLike will be returning exactly the window I want (silly for loop, I know). So could it send it to the wrong window? If so, what could one way be of fixing this, perhaps WaitWindow?

Replies are listed 'Best First'.
Re: Is GUITest SetForegroundWindow/Sendkey thread safe?
by BrowserUk (Patriarch) on Mar 26, 2014 at 16:54 UTC
    • First thing. This has nothing whatever to do with "thread safety".
    • Imagine that there is another copy of your program also running on the machine but looking for a different window.

      If your program calls SetForegroundWindow(), and then reaches the end of its timeslice and gets preempted; then the other program might call SetForegroundWindow before your program gets around to calling SendKeys().

      With just two programs with two actions (SFW & SK) each, there are six possibilities for the ordering of those 4 actions:

      A A A B B B A B B A A B B A B B A A B B A A B A

      Only two will produce the desired result for both programs.

    • If so, what could one way be of fixing this,

      The only sure way would be to wrap the two actions in a Critical Section.

      This isn't (cannot easily be) available to Perl code.


    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.

      Sad to hear that's the case, but thanks for the information nonetheless. I'll try to come up with a different solution which doesn't require me finding a unique name & sending a key to it. :)

        Sad to hear that's the case

        You could greatly increase your chances of not getting interrupted at an inopportune moment by (temporarily) raising the priority of your process.

        Of course, if the other application takes the same approach, your back to square one.

        I'll try to come up with a different solution which doesn't require me finding a unique name & sending a key to it. :)

        If you tell us what application your driving, someone might have another solution.


        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.

        Sorta sounds like you have control over both the driven and driving sides of the system. How about you tell us a little more about what you want to achieve and we may be able to offer an alternative way to solve the problem (about three different ways spring to mind depending on what you need to do).

        <c>
        Perl is the programming world's equivalent of English
Re: Is GUITest SetForegroundWindow/Sendkey thread safe?
by Anonymous Monk on Mar 26, 2014 at 23:35 UTC