[Webkit-unassigned] [Bug 223069] REGRESSION(r271560): [Linux] release assert in Thread::initializePlatformThreading

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=223069

--- Comment #6 from Yusuke Suzuki <ysuzuki at apple.com> ---
(In reply to Alberto Garcia from comment #5)
> (In reply to Yusuke Suzuki from comment #4)
> > > Some possible alternatives:
> > >
> > > 1) Keep the previous behavior and don't abort if SIGUSR1 was
> > > already being handled. Optionally emit a warning.
> 
> > In this case, what signal handler is installed? If JSC signal
> > handler is not set, then JSC will not work. On the other hand, is it
> > OK to discard ruby's signal handler?
> 
> In this case the JSC handler would be installed, overriding the
> previous one.
> 
> What I'm trying to avoid is that an app that was working fine suddenly
> breaks after upgrading WebKit (as this bug report shows). Even if the
> cost is that an app that was already broken remains broken.
> 
> In the case of Ruby: I just took a look at the code now and as far as
> I can see the only reason why it is handling SIGUSR1 (among others) is
> to run any potential handler for those signals in the Ruby script
> being executed.
> 
> So yes, if a Ruby script needs to handle the same signal that JSC is
> using then there is a problem. I understand that this is true in
> general for any WebKit embedder.

I think it is OK to remove this RELEASE_ASSERT for now, and we should also open a bug in Ruby binding implementations to configure JSC signal from SIGUSR1 to different one instead (e.g. SIGPWR, SIGXCPU etc.).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210318/eb19b0c2/attachment.htm>