Your skill will accomplish what the force of many cannot |
|
PerlMonks |
Re^2: Synchronising threads with signals (or not)by BrowserUk (Patriarch) |
on Feb 23, 2013 at 07:28 UTC ( [id://1020283]=note: print w/replies, xml ) | Need Help?? |
I see that my approach has been totally bum-over-tits so I consider this case closed :) Hm. Just because the initial approach is bad, it doesn't mean that the over all goal is unobtainable. Eg. This almost does what you asked for (note the Inline::C bit is only to get accurate timings; it doesn't affect what the code does):
NB: ms above is microseconds! But note that even on my 4 core system, the 2 threads do not see the signal at exactly the same time. (also, if you leave it running, you'll see one of the limitations (a.k.a total idiocies) of the cond_var mechanism. But that brings me back to the questions I alluded to earlier. Why have your main thread attempt to coordinate starting two other threads; and then just sit there doing nothing? Ie, why use 3 threads? I can see that you might need to run the recorder and player from different threads, but why not:
This mirrors what you'd do manually. Switch the recorder on; switch the player on; when the player finishes; switch the recorder off. There is plenty of scope for solving the problem; you just need to tackle it the right way. 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.
In Section
Seekers of Perl Wisdom
|
|