From: Aaron Patterson Date: 2012-04-17T00:24:23+09:00 Subject: [ruby-core:44391] Re: [ruby-trunk - Feature #6293][Assigned] new queue / blocking queues --ftEhullJWpWg/VHq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 16, 2012 at 06:25:59PM +0900, SASADA Koichi wrote: > Hi, >=20 > Just an idea. >=20 > (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: > >=20 > > queue.pop(true) # does "true" mean I enable blocking?=20 > > queue.pop(false) # does "false" mean I disable blocking? > >=20 > > It seems confusing to me, especially given the *actual* api with > > twists your brain with a double negative (from thread.rb): > >=20 > > def pop(non_block=3Dfalse) ... end > >=20 > > So calling pop() means we're doing a not not blocking call. :( >=20 > How about to add try_pop? try_pop seems fine, but it still seems strange to combine blocking and non-blocking queues (but maybe *I* am the one who is strange). In the case of BlockingQueue#pop in the patch I submitted, it allows a timeout. I don't think it's a feature that should be abandoned. > >>> * include Enumerable > >>=20 > >> The semantics is not trivial. See the discussion in #4589. > >=20 > > 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. > >=20 > > 1. > > http://docs.oracle.com/javase/6/docs/api/java/util/Queue.html#methods_i= nherited_from_class_java.util.Collection >=20 > How > >=20 > about to implement Queue#to_a method that generate array which > contains queues containing objects? That seems fine! Then we can eliminate Enumerable mixed in. :-) > # 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. Yes. I think keeping ::Queue is good. I think ::Queue can be implemented in terms of Thread::BlockingQueue. I would have refactored ::Queue to be a subclass of Thread::BlockingQueue, but I didn't want my patch to be ignored because the diff size. :-) --=20 Aaron Patterson http://tenderlovemaking.com/ --ftEhullJWpWg/VHq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iQEcBAEBAgAGBQJPjDmmAAoJEJUxcLy0/6/Gg9IIAIZHeC7S5+ZYuifgmjeLQeUX OekqR8gP02aokRncO/XsQPWVy8rnTp7QPznYcmTkMeB4ZcBis075pMg/7ehKvjea uMjIuM63CQDNz5KzCK04aoHHuW1RNeWQfB4wDNCceMnrM6kb/za/fk6IMzH3RzrE cdPcy7sBJKtH1X/lp8L1noIYIF+TJ9ap052skxXlakYzAxg/dXCtseiYdE5hjdp8 j7Gx+jcQ6QkPZbKqTYZbTCM0516QGBjpVB++W1oSMMtFX/QRSTTyZDWvUs2OLytV aTqc2yXvVQ1QfZER1BH3kkpzmkwTANJ7xSsCLlpYGf7hj/Rwx3ZZhhkbo17mFac= =mM2W -----END PGP SIGNATURE----- --ftEhullJWpWg/VHq--