Ryan Davis wrote:
>
> 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).
>
>
>
Fair enough. Then the answer to your question is no, using the hook is 
not possible, and probably never will be.

To answer your thread switching concern: there's one method between the 
VM executing the bytecode in vm_exec_core() and my hook 
(exec_event_hooks). It doesn't touch ruby_current_thread. Not much 
mechanism at all; it seems very safe to me, and I have spent hours and 
hours debugging the VM. Also, as a side note, the debugger suspends all 
running threads. It's conceivable to me that there are potential race 
conditions that might cause problems, though.

Further, in practice, I am not getting any bug reports of segfaults 
under the debugger that I have not already attributed to other issues; 
and all such problems are fixed. If you're not comfortable with the 
induction, fine, but to me, that means something.