http://www.perlmonks.org?node_id=1052623


in reply to Re: Get the process id, and output of a process, in a threaded environment
in thread Get the process id, and output of a process, in a threaded environment

Yes, the problem is not caused by threads at all as you said. The only reason I mentioned that aspect, is because setting values for %ENV are not picked up on unix machines unless they are set in the main thread. On windows, your code will work as expected with threads, but unix systems will not pick up those environment changes.

Was writing up an example of my own, but the monk above me beat me to it. Love the community :)

  • Comment on Re^2: Get the process id, and output of a process, in a threaded environment

Replies are listed 'Best First'.
Re^3: Get the process id, and output of a process, in a threaded environment
by BrowserUk (Patriarch) on Sep 05, 2013 at 21:47 UTC

    Then -- with the caveat that I don't have a non-Windows system to hand to test this -- make the changes in main before you spawn the thread. Eg:

    { my $running : shared = 0; local %ENV = %ENV; $ENV{ FOO } = 'BAR'; async{ my $pid = open ...; $running = 1; ... kill ... }->detach; ## Wait until the kid is spawned before exiting the scope. sleep 1 until $running; } ## And repeat till done.

    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.

      That would be a way to go about it. Unfortunately however, I am using a thread pool (as you and I have previously decided would be best solution for the application described in this thread, which has undergone a number of improvements but overall structure is the same), so any option of setting the environment before thread creation is out of the question, as it will need to constantly change on a per command basis.

      I'll update my original post to have a more clear description of my script

        I've thought about this overnight and I don't have any good news for you.

        If *nix doesn't allow you to control the environment that a child process gets when it is spawned from a thread, that's not the fault of nor can it be influenced or corrected by anything you do in your Perl code.

        One alternative I can come up with is that you write your own 'shell' that in addition to doing the require SETs and forking the command, somehow conveys the pid of the forked process back to its parent (your Perl script).

        Maybe, it could arrange for the child's pid to be returned as the first line that is read from the pipe?

        Another alternative (that I'm barely aware of what might be possible), is to use the memory mapped file structure (is it /dev/...?) to discover the child's pid. I'll leave that idea hanging their cos I don't know enough to know if it is possible or portable.

        If you arrive at a solution, please be sure to come back and tell us how you did it, because I can see that it is something others would find useful.


        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.