On Sep 29, 2009, at 20:02 , Mark Moseley wrote:

> Ryan Davis wrote:
>>
>> On Sep 29, 2009, at 01:03 , Mark Moseley wrote:
>>
>>> The hook works fine, it just doesn't pass in the id and klass  
>>> variables. You can get them pretty easily, though  
>>> (ruby_current_thread->cfp->iseq->defined_method_id and  
>>> ruby_current_thread->cfp->iseq->klass).
>>
>> Neither ruby_current_thread nor rb_thread_t are defined as public,  
>> so I don't see how this is possible (and safe/maintainable). They  
>> appear to be in the private vm_core.h at the base of trunk/1_9.
>>
>> It seems to me that the TODO that I pointed out needs to be  
>> finished for event_hook to be usable.
>>
>> Koichi, are there any plans for this?
>>
> ruby-debug19 relies on this, and is working fairly well, so it's  
> clearly possible. It would be good if Koichi would address the safe/ 
> maintainable question, though; that's a good point.

No. ruby-debug19(-base) relies on your ruby_core_source gem... I don't  
think that a hack of that magnitude qualifies as "working fairly  
well". I'd rather write code that works out of the box with the  
version of ruby I'm using.

Further, I don't think your solution is safe. Is there any guarantee  
that threads won't switch between the time that the event is generated  
and the  event_hook is called? There is a LOT of mechanism in there  
and I can't wade through that question (and don't trust it as a result).