ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: Aaron Patterson <tenderlove@ruby-lang.org>
To: ruby-core@ruby-lang.org
Subject: [ruby-core:48584] Re: [ruby-trunk - Feature #4589][Feedback] add Queue#each() method and include Enumerable
Date: Tue, 30 Oct 2012 11:36:48 +0900	[thread overview]
Message-ID: <20121030023636.GA97964@higgins.local> (raw)
In-Reply-To: <redmine.journal-31942.20121030084345@ruby-lang.org>

On Tue, Oct 30, 2012 at 08:44:21AM +0900, ko1 (Koichi Sasada) wrote:
> 
> Issue #4589 has been updated by ko1 (Koichi Sasada).
> 
> Status changed from Assigned to Feedback
> Target version set to next minor
> 
> Professional's comments are very welcome.
> I can't determine it should be worth or not.

I don't think it's a good idea.  There are different ways to make a
thread-safe `each`, and they have different behavior.  For example:

  class Queue
    def each(&block)
      @mutex.synchronize {
        @que.each(&block)
      }
    end
  end

compared to:

  class Queue
    def each(&block)
      @que.dup.each(&block)
    end
  end

Both provide each, but the semantics are totally different.  The first
one ensures that no other threads will update the queue, but that blocks
any threads from updating the queue.  The second one doesn't block the
queue, but the values yielded to the block are inconsistent (e.g., a
thread could write to the queue after the internal array has been duped).

I think it's better to do this:

  class Queue
    def synchronize
      @mutex.synchronize { yield }
    end

    def to_a; @que.dup; end
  end

As a user, it's obvious you're getting a copy:

  queue = Queue.new
  queue.to_a.each { |item| ... }

If you want to block other threads from manipulating the queue while
iterating:

  queue = Queue.new
  queue.synchronize do
    queue.to_a.each { |item| ... }
  end

TL;DR: adding `sychronize` and `to_a` would be more powerful and less
invasive than adding `each` (IMO).

-- 
Aaron Patterson
http://tenderlovemaking.com/

  reply	other threads:[~2012-10-30  2:25 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-20 12:49 [ruby-core:35828] [Ruby 1.9 - Feature #4589][Open] add Queue#each() method and include Enumerable redmine
2011-04-27  4:06 ` [ruby-core:35920] [Ruby 1.9 - Feature #4589] " Charles Nutter
2011-04-28 21:52 ` [ruby-core:35941] " Eric Hodel
2011-07-26 18:21 ` [ruby-core:38528] " Suraj Kurapati
2011-07-26 23:34 ` [ruby-core:38536] " Eric Hodel
2011-07-27  9:41   ` [ruby-core:38559] " Alex Young
2012-03-25  6:20 ` [ruby-core:43618] [ruby-trunk - Feature #4589][Assigned] " mame (Yusuke Endoh)
2012-10-29 23:44 ` [ruby-core:48561] [ruby-trunk - Feature #4589][Feedback] " ko1 (Koichi Sasada)
2012-10-30  2:36   ` Aaron Patterson [this message]
2017-01-31  9:10 ` [ruby-core:79348] [Ruby trunk Feature#4589][Closed] " ko1

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121030023636.GA97964@higgins.local \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).