|Problems? Is your data what you think it is?|
Re^3: Signals vs. Windowsby BrowserUk (Pope)
|on Oct 04, 2012 at 14:34 UTC||Need Help??|
Note that your example still uses the devilish signal.
Yes, but in the way it was intended -- as an IPC mechanism, not ITC.
Resolves the blocking I/O by pushing it another thread deeper. Thank you.
Indeed. (Be sure to look at the stack_size parameter to threads.)
But, it isn't actually necessary to go one thread deeper. If your current main/parent thread can attempt to send a signal to its child threads to terminate them, it could also send that signal directly to the processes those child threads are waiting on, thus cutting out the middle man and the need for an extra thread.
All that would be required is to shared the pids of those processes with the parent thread so that it knows where to send the signal when the time is right.
The following script starts 5 asynchronous, piped subprocesses in threads that will each run for 5 seconds producing one 'line' of output per second. The threads share the pids of those processes with the main thread via a shared array indexed by their thread ids.
The main thread then applies timeouts to those processes ranging from 3 to 7 seconds, killing them after the appropriate delay. It then gathers whatever output they had produced before the timeout from the threads by joining them.
You can see -- in the console output after the __END__ -- that the first two processes were terminated (SIGINT) after 3 and 4 seconds respectively and their output was truncated. The other 3 complete their output and terminate normally.
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.