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

Hi,

At Tue, 20 Jul 2010 04:21:37 +0900,
Ricardo Panaggio wrote in [ruby-core:31358]:
> (Caleb shared this idea with me) Wouldn't it be good to wake up all
> threads from @waiting before freeing the Queue, so that they can raise
> the proper exceptions? This way, the kill could be treated more
> properly.

Because dfree function is called *after* the objects were
collected.  Your benchmark segfaulted soon as the first run
ended.

> I don't get how memsize works. I mean, condvar_memsize, queue_memsize
> and szqueue_memsize have a lot in common. If they are correct (and I
> assume they are), then I assume that thread_memsize and
> thgroup_memsize might not be, as the respective structs have fields of
> common types, and the _memsize's are not coherent with the structs
> definition.

Because I changed the member objects to be hidden, so the
memory used by these objects can't be counted with ObjectSpace.

> And I didn't get why the RBASIC from queue_initialize is there. Why
> should it be treated as a generic object, rather than its original
> class? It may have a purpose, I just was wondering what it was. I
> couldn't manage to understand that by myself =/

To hide the internal member from the ObjectSpace.

> And, my last question, should I implement other sync primitives with
> or without the Thread namespace? I see that you've put C
> implementations for Queue, SizedQueue and ConditionVariable in there,
> but will the ruby implementations be kept? Will they be outside any
> namespace? Should I implement new sync primitives directly in C only,
> or it's good to implement them in both ruby and C? Should I keep C
> implementations inside Thread and ruby implementations without a
> namespace?

Just I wanted to run the benchmark at once.

> Sorry for being so much pedantic. I just want to be sure that I can
> help more on my next patches, writing better code, that could be
> reviewed more easily, and that could improve ruby better =)
> 
> Thanks for all the help!

Thanks for the contribution.

-- 
Nobu Nakada