> Why is it called on another thread? Actually, POSIX specifies that in a multithreaded applications a signal sent to a process is delivered to an arbitrary thread that isn't blocking the signal. This was quickly revealed on Mac, where initially profiling didn't worked on Chromium at all just because renderer thread had almost never received SIGPROF signal. On Linux for some reason SIGPROF is often delivered to a renderer, but not always.
> From what I can see this will only work when V8 is only ever used from > one thread, as is the case for the Chromium renderer process. However if > different threads are using V8 then this will only get samples from one > of these. But, e.g. in Windows implementation there is only one profiled thread, and there can't be more, because Ticker (derived from Sampler) has a single instance in Log. I can try to look for another implementation. The common practice is to block all unneeded signals in the main thread (and this property will be inherited by child threads), and then only unblock signals in threads where this is needed. However, as V8 is a library rather than application, this isn't look feasible. On Wed, Sep 2, 2009 at 14:32, <[email protected]> wrote: > Why is it called on another thread? > > http://codereview.chromium.org/171115 > --~--~---------~--~----~------------~-------~--~----~ v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev -~----------~----~----~----~------~----~------~--~---
