Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Thead.parent, revisited. Or: Building a call stack.

Reply
Thread Tools

Thead.parent, revisited. Or: Building a call stack.

 
 
Erik Veenstra
Guest
Posts: n/a
 
      03-05-2007
In order to build a diagram of all method calls in an
application, I created a set_trace_func function. This function
builds a call stack. Each thread in each process should have
its own call stack, initialized to the call stack of the parent
process or the parent thread.

The call stacks are stored in the array stack_per_thread. The
initial call stack is an empty array:

stack_per_thread = []
stack_per_thread[[Process.pid, Thread.current]] = []

Creating a new call stack after a fork (both process fork and
thread fork) is done like this:

stack = (stack_per_thread[[Process.pid, Thread.current]] ||=
stack.dup)

Process forks are not a problem, since the last call stack
before the process fork is the one with which the child process
has to continue and does continue.

However, threads are a bit of a problem. Threads don't have a
parent, which means that it's not possible to clone the call
stack of the parent thread. I currently fake the concept
"parent thread" by assuming that the last running thread is the
parent thread.

If Parent.thread existed, everything would be perfectly fine:

stack = (stack_per_thread[[Process.pid, Thread.current]] ||=
stack_per_thread[[Process.pid, Thread.parent]].dup)

I observed a couple of traces and noticed, empirically, that a
new thread always gets a couple of CPU cycles (and hence calls
to set_trace_func). If this is always true, my assumption ("the
last thread is the parent thread") is no problem. If the parent
process can spawn many threads before any of them gets some CPU
cycles, well, then we do have a problem... :{

Ideas? Related work? Anybody able to understand the C code?
Matz?... :}

gegroet,
Erik V. - http://www.erikveen.dds.nl/


 
Reply With Quote
 
 
 
 
ara.t.howard@noaa.gov
Guest
Posts: n/a
 
      03-05-2007
On Tue, 6 Mar 2007, Erik Veenstra wrote:

> In order to build a diagram of all method calls in an
> application, I created a set_trace_func function. This function
> builds a call stack. Each thread in each process should have
> its own call stack, initialized to the call stack of the parent
> process or the parent thread.
>
> The call stacks are stored in the array stack_per_thread. The
> initial call stack is an empty array:
>
> stack_per_thread = []
> stack_per_thread[[Process.pid, Thread.current]] = []
>
> Creating a new call stack after a fork (both process fork and
> thread fork) is done like this:
>
> stack = (stack_per_thread[[Process.pid, Thread.current]] ||=
> stack.dup)
>
> Process forks are not a problem, since the last call stack
> before the process fork is the one with which the child process
> has to continue and does continue.
>
> However, threads are a bit of a problem. Threads don't have a
> parent, which means that it's not possible to clone the call
> stack of the parent thread. I currently fake the concept
> "parent thread" by assuming that the last running thread is the
> parent thread.
>
> If Parent.thread existed, everything would be perfectly fine:
>
> stack = (stack_per_thread[[Process.pid, Thread.current]] ||=
> stack_per_thread[[Process.pid, Thread.parent]].dup)
>
> I observed a couple of traces and noticed, empirically, that a
> new thread always gets a couple of CPU cycles (and hence calls
> to set_trace_func). If this is always true, my assumption ("the
> last thread is the parent thread") is no problem. If the parent
> process can spawn many threads before any of them gets some CPU
> cycles, well, then we do have a problem... :{
>
> Ideas? Related work? Anybody able to understand the C code?
> Matz?... :}


class Thread
class << self
alias_method "__new__", "new"
def new *a, &b
child '__new__', *a, &b
end
alias_method "__start__", "start"
def start *a, &b
child '__start__', *a, &b
end
private
def child as, *a, &b
parent = Thread.current
send(as, *a) do |*a|
Thread.current.parent = parent
b.call *a
end
end
end
def parent
self['parent']
end
def parent= parent
self['parent'] = parent
end
def ancestors
return self['ancestors'] if self['ancestors']
list = [t = self]
while((t = t.parent))
list << t
end
self['ancestors'] = list
end
end


-a
--
be kind whenever possible... it is always possible.
- the dalai lama

 
Reply With Quote
 
 
 
 
Erik Veenstra
Guest
Posts: n/a
 
      03-05-2007
Yep, I know. That's a "work around". But, as we've discussed
before [1], it's not water tight.

"Thread#start doesn't reuse Thread.new. Neither does
rb_thread_create(), which is used in e.g. TK."

Thanks.

gegroet,
Erik V. - http://www.erikveen.dds.nl/

[1] http://tinyurl.com/38823g


 
Reply With Quote
 
ara.t.howard@noaa.gov
Guest
Posts: n/a
 
      03-05-2007
On Tue, 6 Mar 2007, Erik Veenstra wrote:

> Yep, I know. That's a "work around". But, as we've discussed
> before [1], it's not water tight.
>
> "Thread#start doesn't reuse Thread.new. Neither does
> rb_thread_create(), which is used in e.g. TK."


oh right. forgot.

check out ThreadGroup - i think it's properties may allow someone to hack what
you're after. just looking at that today - but out of time now...

-a
--
be kind whenever possible... it is always possible.
- the dalai lama

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Link Building Services| Link Building Company|Webs abrahim Java 0 12-27-2009 02:31 PM
Connecting Wireless Network from Building to Building Jim Wireless Networking 5 10-05-2007 03:54 PM
Firefighters at the site of WTC7 "Move away the building is going to blow up, get back the building is going to blow up." Midex Python 24 05-07-2007 04:23 AM
Wireless building-to-building 101 Tim Jacob Wireless Networking 2 02-17-2006 09:46 AM
Building to Building wireless Patriot Cisco 2 11-04-2003 05:07 PM



Advertisments