Geez, you guys!

@BrowserUK: Maybe he means what he said in his first post:

Each of the worker threads is essentially independent and can run perl code as well as do system() calls.

@that_guy: Maybe he wanted you to explain specifically what you are doing (e.g. give an example of some of the "perl code" each thread is supposed to run) when he said:

if you can describe what it is that you need to do; rather than how you are currently trying to do "it"; then I might be able to help

You're welcome :-) I'm hoping to learn something here . . .

@1nickt I have submitted code with a minimal example of what I want to do . In reality code that processes are going to run the most general things -- often submitting jobs to sungrid engine or calling standalone programs of which I have no control.

@BrowserUK I guess I have drawn distinction between STDOUT and STDERR produced by perl code and by program run by system() call because they have shown to behave differently in my example code. Looks like you're suggesting that they should behave the same way. Perhaps they should - I'm not sure. We can go with your assumption that they should. In which case I want to capture STDOUT and STDERR of each worker "process".

In which case I want to capture STDOUT and STDERR of each worker "process".

And there is the source of my question: Why are you quoting "process"?

Either this is

1. a real separate process;

   In which case you need to 'capture' the output from STDOUT and STDERR.

2. Or it is just perl code running in a thread; and using the term 'process' is just misleading.

   In this case you don't need to 'capture' the output; you simply need to direct it to where you want it to go.

   Ie. If you are going to call a subroutine that normally writes to stdout and stderr; and you want that output to end up in a file of your choosing, then point stdout and stderr to that file before you call the subroutine:

   sub worker {
       local( *STDOUT, *STDERR );
       open STDOUT, '>', 'my.log' or die $!;
       open STDERR, '>&STDOUT' or die $!;
       unmodifiable(); ## call the code that produces the output; it'll e
   +nd up in my.log
       ## the effects of the redirection get cleaned up automatically whe
   +n the worker ends.
   }
   [download]

---

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". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.

I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!

Geez, you guys! @BrowserUK: Maybe he means what he said in his first post: Each of the worker threads is essentially independent and can run perl code as well as do system() calls.

@1nickt.[sic] If you know better; feel free to answer his question. Maybe you can teach me something?

---

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". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.

I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!

I doubt anyone can teach you anything. Especially not what a sense of humour is!

Since you appear to have missed the point, in my good-natured post nudging the guy with question and the guy with the answer to just get on with it, I'll restate that I learn something from everything you share.

Now carry on :-)

The way forward always starts with a minimal test.