--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--

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/
-----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-----