From: SASADA Koichi <ko1@...>
Date: 2012-04-16T18:25:59+09:00
Subject: [ruby-core:44384] Re: [ruby-trunk - Feature #6293][Assigned] new queue / blocking queues

Hi,

Just an idea.

(2012/04/14 11:25), Aaron Patterson wrote:
> I could, but I think the changes I want would add too much
> complexity to the traditional Queue class.  We have to add
> branching code for every method that could block / not-block.  Not
> to mention users must pass the magical true | false to indicate if
> they want blocking or non-blocking behavior.  For example:
> 
> queue.pop(true)  # does "true" mean I enable blocking? 
> queue.pop(false) # does "false" mean I disable blocking?
> 
> It seems confusing to me, especially given the *actual* api with
> twists your brain with a double negative (from thread.rb):
> 
> def pop(non_block=false) ... end
> 
> So calling pop() means we're doing a not not blocking call. :(

How about to add try_pop?

>>> * include Enumerable
>> 
>> The semantics is not trivial.  See the discussion in #4589.
> 
> I've read #4589.  I don't think it's that much of a problem.
> Other languages[1] include enumerable type behavior in their
> queues, and consistency is not guaranteed.
> 
> 1.
> http://docs.oracle.com/javase/6/docs/api/java/util/Queue.html#methods_inherited_from_class_java.util.Collection

How
> 
about to implement Queue#to_a method that generate array which
contains queues containing objects?


# I agree the name Thread::Queue because it is clear
# that this object should be for synchronization.
# Simple Queue class is ambiguous that we can use it
# for synchronization or not.  However, in the Ruby world,
# ::Queue is familiar as a data for synchronization.

-- 
// SASADA Koichi at atdot dot net