I do not claim to have found a bug with any of the perl threading modules.
I suppose you could have meant that you thought were misusing the module. But that doesn't change anything. The question I asked ("How did you arrive to that conclusion?") still applied. You specified a very specific problem (the lock on the queue isn't being released) without showing any evidence of that. You didn't even mention where the code blocks! It's hard to debug a problem without knowing anything about it.
In fact, from looking at the code you have since posted, I suspect the opposite problem. It's not one of your threads blocking itself to oblivion, it's one of your threads not waiting at all.
Unless there's already something in the queue, that function will exit immediately after being called since $q->dequeue_nb will return undef. The function will also exit as soon as the queue is empties, even if more items will later be added to it.
That's not necessarily a problem. I don't know how process_output is used. But if I were to venture a guess at what the rest of the code looks like, $q->dequeue_nb should be $q->dequeue.
There's a second issue. If you put an empty string or the number zero in the queue, the loop will exit prematurely.
while ( my $line = $q->dequeue_nb() ) or
while ( my $line = $q->dequeue() )
should be
while ( defined( my $line = $q->dequeue_nb() ) ) or
while ( defined( my $line = $q->dequeue() ) )
since those methods could return false value when they aren't
Finally, it's really weird to see use Text::CSV; inside a function. Do you understand that the statement will execute when process_output is compiled (even if it's never called), and not when process_output is called? It would be better if you put it at the top of your program.
Update: Readability enhancements.
In reply to Re^3: Thread::Queue locking question
by ikegami
in thread Thread::Queue locking question
by mhearse
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |