Re^4: Signals vs. Windows

in reply to Re^3: Signals vs. Windows
in thread Signals vs. Windows

Yes, I thought about that. But the child thread is doing more than just executing the command. It is also logging the output, start, stop, status.... I'd like the child thread to ultimately send the signal to external program so that it can also record the fact in my log.

But that's all okay because now the child thread is running asychonously and I can move the timer from the parent down to the child. So in essence, the parent no longer needs to signal the child, and logically you are right that we don't need to be another level deep, but that I am really moving down a level in my hierarchy of threads.

Comment on Re^4: Signals vs. Windows

Replies are listed 'Best First'.
Re^5: Signals vs. Windows by BrowserUk (Patriarch) on Oct 04, 2012 at 15:13 UTC
But the child thread is doing more than just executing the command. It is also logging the output, start, stop, status.... I see no conflict with that and what I posted accept that instead of the parent setting the end time when it starts the thread, you have the kids set the end time -- in a shared data structure -- when it starts the process. Either way works, but if all your main thread is going to do while the kids are doing their thing is wait for them, I see no reason not to have it make itself useful and fulfill the timeout roll. Saving a second layer of threads is just a bonus. But whichever works for you ... 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. RIP Neil Armstrong	[reply]

Replies are listed 'Best First'.

Re^5: Signals vs. Windows
by BrowserUk (Patriarch) on Oct 04, 2012 at 15:13 UTC

But the child thread is doing more than just executing the command. It is also logging the output, start, stop, status....

I see no conflict with that and what I posted accept that instead of the parent setting the end time when it starts the thread, you have the kids set the end time -- in a shared data structure -- when it starts the process.

Either way works, but if all your main thread is going to do while the kids are doing their thing is wait for them, I see no reason not to have it make itself useful and fulfill the timeout roll. Saving a second layer of threads is just a bonus.

But whichever works for you ...

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.

RIP Neil Armstrong

[reply]

In Section Seekers of Perl Wisdom