Re^2: failing with Thread::Queue

Omg BrowserUK, thank you so much. I had tried using a simple shared scalar before, but I thought I had to use cond_wait() and locking and friends and I was having a devil of a time. (Actually I had meant to remove those $done lines from the code I posted here for clarity's sake). I tried what you showed and it worked just fine :-)

And I now see how what I did could never work. I think the term for that is "having sh*t for brains" on my part. I moved the $q->enqueue(1) to before the creation of the threads, and it worked as expected. I think it's time for a break :-)

Just out of curiousity, why are those methods so bad?

Comment on Re^2: failing with Thread::Queue

Replies are listed 'Best First'.
Re^3: failing with Thread::Queue by BrowserUk (Patriarch) on Mar 22, 2012 at 21:36 UTC
Re-reading your post, I should also comment on: I had tried using a simple shared scalar before, but I thought I had to use cond_wait() and locking and friends Technically, you should use locking on shared vars. You will rarely, if ever, need to use cond_(), and I would suggest you pretend they don't exist until you encounter the situation that you cannot deal with without them. I write a lot of threaded code, and I've only had to use them about 3 or 4 time in total over the past 8 or 9 years. For this specific case, even the need for lock is moot. The shared var is either true or false. When the value is about to change, readers will either see it just before it changes and loop once more, or they will see it just after it changed and terminate. Locking it before changing it; or before reading it; will make no quantifiable difference to the order in which things happen; it is therefore redundant -- in this case!* 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. The start of some sanity?	[reply]
Re^4: failing with Thread::Queue by rastoboy (Monk) on Mar 22, 2012 at 22:10 UTC
Awesome, thanks. Makes perfect sense. :-)	[reply]
Re^3: failing with Thread::Queue by BrowserUk (Patriarch) on Mar 22, 2012 at 21:22 UTC
Just out of curiousity, why are those methods so bad? Because a queue is a very simple concept -- you put things in one end and take them out the other in the same order -- and the addition of those methods broke that simple model. The fatuous addition of those methods removes all the guarantees associated with the well-proven abstract data type, rendering it a hybrid mess that is impossible to correctly reason about. It turns a queue (back) into an array -- when the whole purpose of the module is to turn an array into a queue! 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. The start of some sanity?	[reply]