On 2013/08/20 12:25:05, Yury Semikhatsky wrote:
On 2013/08/20 12:13:02, Benedikt Meurer wrote:
> On 2013/08/20 12:07:36, Yury Semikhatsky wrote:
> > On 2013/08/20 11:58:56, Benedikt Meurer wrote:
> > > What's the benefit of this change, other than trying to somehow
unify
the
> code
> > > paths?
> >
> > Just unification of the code no obvious performance gains at the
moment.
After
> > this change all but Windows port use the same mechanism based on
signals.
>
> Well previously Mac and Windows ports were using the same mechanism and
everyone
> else was using signals because of the lack of thread_suspend/resume.
>
> Personally I think the thread_suspend/resume approach is cleaner and
less
likely
> to break compared to the SIGPROF approach, so I'm not in favor of using
signals
> on the Mac unless there's a good reason to do so.
Thread suspend/resume code is platform dependent while signal API is the
same
on
all platforms which means that we have fewer platform-specific pieces in
the
sampler implementation. Why do you think that suspend/resume is less
likely to
break compared to the SIGPROF approach?
Because only very few functions are actually signal-safe. For example, I'm
pretty sure that backtrace() and friends is NOT signal-safe, so calling this
from a signal handler might cause trouble every once in a while.
Unfortunately
Linux lacks a "portable way" (in the sense that it's portable across
different
libpthread/libc implementations) to suspend/resume a thread, so we have to
use
the POSIX signals here and pray that we don't crash even tho we don't pay
attention not to call any non-signal-safe functions.
https://chromiumcodereview.appspot.com/23115005/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
