in reply to Re^7: Proper undefine queue with multithreads
in thread Proper undefine queue with multithreads

It does have a race condition. Explained and solved here
  • Comment on Re^8: Proper undefine queue with multithreads

Replies are listed 'Best First'.
Re^9: Proper undefine queue with multithreads
by Anonymous Monk on Jun 06, 2014 at 11:20 UTC
    ikegami, the queue does locking, doesn't make sense to add locking on top of that
[reply]
      It's not locking long enough. There's a step by step demonstration of the race condition in the linked post.
[reply]

        It's not locking long enough. There's a step by step demonstration of the race condition in the linked post.

        Maybe there is a chance of this occuring with sleep 0.01 but BrowserUk originally had sleeps of 1 -- I doubt this race condition could ever manifest with more than one worker .... esp when you're not using pending (like originally)... but even with the ops changed code and pending

        Isn't it simpler to just 

        for( 1..10 ){ ## make sure we're not between DQ and $busy++
    sleep 1;
    sleep 1 while $q->pending || $busy;
}

        [download]

        I can't quantify the odds exactly other than to say probably never

[reply]
[d/l]

In Section Seekers of Perl Wisdom