in reply to Re: capturing output of system call inside a thread
in thread capturing output of system call inside a thread

Thanks for the reply. I'm fully aware that all for this can be rewritten much more concise. This doesn't solve my problem though. I'm also aware that join is blocking which is why I don't want to join the thread while other thread might be running thus providing the parallel execution of all the threads. I've tried local STDOUT and local STDERR call and it gives strange results as well. Looks like after using it, most of the output goes to the screen for whatever reason.
  • Comment on Re^2: capturing output of system call inside a thread

Replies are listed 'Best First'.
Re^3: capturing output of system call inside a thread
by SimonPratt (Friar) on Sep 07, 2015 at 11:43 UTC

    I see that your original problem has been resolved, but will still comment on a misunderstanding you appear to have about threading.

    When I say that join is blocking, it blocks only the thread that is calling the join. Because threads are run in parallel and are essentially independent of each other, calling join in one thread has no effect on the processing of any other threads. In fact, because join is blocking, it is preferable for the parent thread to call join on at least one sub-thread as soon as possible, to minimise the resources the parent thread is consuming (and hence making those additional resources available for the sub threads).

    The main point about writing code more concisely is that it makes your program easier to understand and follow. Doing something in 40 lines that can be easily written and understood in 2 lines makes life a lot harder for anyone trying to understand what you're doing. (Do keep in mind the distinction between minimising code and obfuscating code).