[ruby-core:31330] Re: [rubysoc] Queue C-extension patch to come

> Visual representation of your changes, commit and files

> http://github.com/panaggio/ruby/compare/ruby:trunk...queue

Thanks for the help Luis

> Which static functions?  It looks like everything you're using is public
> api.  Am I missing something?

My mistake. Before working on that branch, I've started working in a
toy port using mutext_t and a lot of statics from thread.c. As I've
started working on that branch, I've decided to use the more
non-statics I could. And now it seems I use little (maybe no) statics
at all. Thanks Aaron to point it out.

> It looks like this patch is just a port of the ruby code to C, but not
> using a native queue system.

As Caleb already said, afaik there's no native Queue system in
pthreads or win32 threads, or related libraries. If there's any, I
could

> Can you show us benchmarks between this
> version and the pure ruby implementation?

Again, as Caleb said, C is much faster than Ruby, and for me that was
ok to go just with that. But as asked, I'm working on benchmarking
now. As soon as I have useful results, I'll show them.

> Also, it looks like you're not tainting objects like the original Queue
> class is.

Again, my mistake. I'll get the code corrected, but "in the dark". I
just didn't get why it's necessary, and maybe that's why I forgot it.
Any one can give some help? Tainting is only use in Queue, which makes
it more strange for me and more difficult to understand it.

> Are there benchmarks showing that the Ruby code is so slow (in an
> actual usage scenario) that a rewrite in C (which can稚 be used by
> JRuby and similar) really is needed?

Ruby is used on a lot of different scenarios, for different purposes,
with different interpreters, and a lot of other differences that I
will just pass, as this  is enough for my point.

Working on something that would make everyone benefit is kind of the
best way to do it, always. But sometimes, we can work for an specific
(and my patch is not so specific as it may seem), and make it much
better.

It's difficult to show that my patch will make ruby 2x faster (but
I'll try to show how faster it gets anyway). Specially when talking
about an "actual usage scenario". There are a lot of uses for Queue,
and without extensively testing it, I couldn't say that it's really
faster, in any purpose.

I see if there any benefit of accepting it (even if small), it would
be of help, specially in a near future. There are plans for evolving
Ruby threads, and as we get to stage 3, sync primitives will be an
issue, I'm sure. If I can help now to make things better now, knowing
that it'll be even better later, I just can't see why it's not good
enough.

If there's any other mistakes on the code, just let it come. As I'm
already working on SizedQueue, anything found on Queue may affect it.
And may affect the performance also.

Again, thanks for all the help until now.