[tor-dev] Using Shadow to increase agility of Sponsor R deliverables
rob.g.jansen at nrl.navy.mil
Fri Nov 21 17:59:43 UTC 2014
> On Nov 21, 2014, at 10:40 AM, David Goulet <dgoulet at ev0ke.net> wrote:
> Please see https://trac.torproject.org/projects/tor/ticket/13802 about
> the instrumentation part. We'll definitely have to talk more on the
> integration of Shadow and a userspace tracer but of what I got from
> Nick, it sounds totally doable without too much trouble.
If we want the tracer to also work inside of Shadow, then the biggest potential problem I can think of right now is thread safety. Shadow uses several worker threads, each of which are assigned to run hundreds to thousands of Tor nodes. If Tor is using lttng as a dynamic library and it is not thread-safe, we will run into issues.
One way to avoid those issues could be to statically link lttng to Tor. However, even this could go bad if lttng uses global state, because that would mean that those hundreds of Tor nodes assigned to a Shadow worker thread would be sharing that state. Probably not what we want. To get around the global state issue, Shadow would have to compile lttng specially, using the same LLVM pass to hoist out the global variables as we use for Tor. That may get messy.
So it really depends on how robust lttng is, and as I have no experience with it, I can only speculate. But if you let me know when you have some minimal instrumentation ready, I can test in Shadow early enough that we could adjust if needed.
More information about the tor-dev