[webkit-reviews] review granted: [Bug 187297] [linux] ASSERT: Using an alternative signal stack is not supported. Consider disabling the concurrent GC. : [Attachment 344277] Patch

[bugzilla-daemon at webkit.org]

Mark Lam <mark.lam at apple.com> has granted Yusuke Suzuki
<utatane.tea at gmail.com>'s request for review:
Bug 187297: [linux] ASSERT: Using an alternative signal stack is not supported.
Consider disabling the concurrent GC.
https://bugs.webkit.org/show_bug.cgi?id=187297

Attachment 344277: Patch

https://bugs.webkit.org/attachment.cgi?id=344277&action=review




--- Comment #10 from Mark Lam <mark.lam at apple.com> ---
Comment on attachment 344277
  --> https://bugs.webkit.org/attachment.cgi?id=344277
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=344277&action=review

r=me.  Nice work and very clean.

> Source/WTF/wtf/ThreadingPthreads.cpp:155
> +	   // 1. An user-defined signal handler is invoked with an alternative
signal stack.

/An user-defined/A user-defined/.

> Source/WTF/wtf/ThreadingPthreads.cpp:158
> +	   // 4. A stack pointer saved in a machine context is pointing an
alternative signal stack.

I suggest "The stack pointer saved in the machine context will be pointing to
the alternative signal stack."

>> Source/WTF/wtf/ThreadingPthreads.cpp:371
>> +		Thread::yield();
> 
> Should we wait a bit here? idk.

I think this is fine because I see that we also use Thread::yield() elsewhere
for purposes like this.  Given that the probability of a suspension request
coinciding with a user-defined signal handler is rare, I think we don't need to
worry about any perf issues here.  We already do a wait() in this loop which is
way slower.