Forum: Ruby-core set_trace_func doesn't allow for differentiation of threads?

Posted by Roger Pack (Guest)
on 2009-12-30 23:27
(Received via mailing list)
Currently it appears that within a set_trace_func proc, a call to
Thread.current sometimes returns Thread.main, even when that isn't the
"right" current thread.

(returns 2 in 1.8.x, 1 in 1.9.x):

all_threads = {}
set_trace_func proc {
 all_threads[Thread.current] = true
}

def go; end

Thread.new { go }.join # create a new thread after having called 
set_trace_func

puts all_threads.length # should be 2, I think.

Is this expected?

Anyway, it currently prevents the ruby-prof gem from being able to
assign timings to the correct threads because calls to
rb_thread_current() act the same as the above, so getting this fixed
would be great for the ruby-prof gem.

(Using GET_THREAD also didn't help).

Thanks!
-r
Posted by wanabe (Guest)
on 2009-12-31 10:31
(Received via mailing list)
Hi,

2009/12/31, Roger Pack <rogerdpack2@gmail.com>:
>
> def go; end
>
> Thread.new { go }.join # create a new thread after having called
> set_trace_func
>
> puts all_threads.length # should be 2, I think.
>
> Is this expected?

I guess Thread.current is correct, but new-thread is not traced.
Because set_trace_func affects only living thread on call it.
(please see set_threads_event_flags() in thread.c)

I'm afraid I don't know this is expected or not.
Posted by Roger Pack (Guest)
on 2009-12-31 20:20
(Received via mailing list)
> all_threads = {}
> set_trace_func proc {
>  all_threads[Thread.current] = true
> }

> def go; end

> Thread.new { go }.join # create a new thread after having called set_trace_func

> puts all_threads.length # should be 2, I think.
>
> Is this expected?


> I guess Thread.current is correct, but new-thread is not traced.
> Because set_trace_func affects only living thread on call it.
> (please see set_threads_event_flags() in thread.c)
>
> I'm afraid I don't know this is expected or not.

Appears others have run into this before
http://redmine.ruby-lang.org/issues/show/2012

(my hunch is it's unexpected).

Could the maintainer of thread.c take a look at Mark's patch in ticket
2012?  I'd be happy to add a unit test or two [the above code is a
pretty good unit test for it, actually, and shows how it differs].

Happy New Year.
-r
Please log in before posting. Registration is free and takes only a minute.
Existing account (Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
No account? Register here.