Signal forwarding

[Ian Lance Taylor]

http://golang.org/cl/8712 implements signal forwarding for Go code. I
encouraged the change but I think it merits wider discussion to see if
anybody objects.

The change is this: when Go registers its signal handlers at startup
time, it will see if there is a non-default signal handler already
installed. If there is, then when Go receives a signal, it will check
whether it is currently running Go code. If it is not, it will pass
the signal on to the signal handler that was previously registered.

The goal is to permit Go code in a shared library to run in the same
program image as, say, a Java VM. Forwarding the signal means that if
the Java VM starts up before the Go code, and registers its signal
handlers first, and then the Go code registers its signal handlers,
then if Java code gets a signal, the Go signal handler will see that
it is not running in Go code, will invoke the Java signal handler, and
the right thing will happen.

Does anybody see a problem with this approach, or a reason that the CL
should not be committed? Remember that it only affects the case where
1) a signal handler was registered before the Go signal handler; 2)
that signal occurs while not running Go code (this includes C code
invoked via cgo).

Ian

[Russ Cox]

It seems worth a try, but I do expect problems with existing Go programs that link C++ that has constructor initialization invoked by the dynamic loader before the Go binary gets a chance to start. In that case Go currently overrides the C++ handlers, which I think is probably the right thing to do. 

Perhaps the forwarding could be done only in the shared library mode? It seems likely the runtime would know whether it's the main executable or not.

Russ

[Rob Pike]

Signals are just a nightmare. I defer to experts willing to accept the challenge.

-rob

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ian Lance Taylor]

On Wed, Apr 15, 2015 at 5:40 PM, Russ Cox <r...@golang.org> wrote:
>

> It seems worth a try, but I do expect problems with existing Go programs
> that link C++ that has constructor initialization invoked by the dynamic
> loader before the Go binary gets a chance to start. In that case Go
> currently overrides the C++ handlers, which I think is probably the right
> thing to do.

Right. That case would change: Go would override the C++ signal
handler, and then if Go saw a signal that was not in Go code, it would
invoke the C++ handler.

To me that sounds approximately as correct as what we do today. I
don't see why it's better to use the Go signal handler for non-Go
code. I also don't see why it's worse.

> Perhaps the forwarding could be done only in the shared library mode? It
> seems likely the runtime would know whether it's the main executable or not.

Sure, we can do that, but is that better?

Ian

[Ian Lance Taylor]

Actually, how about this: we only forward the synchronous signals: SEGV, FPE, BUS.  That should do what we want with minimal disruption.

Ian

[Keith Randall]

What about timer signals?  This would change the behavior of the profiler.  Arguably it is better to send all the timer signals to one side or the other (all to Go or all to C) rather than each getting half.  Of course, if both have registered for timer signals something has got to give anyway.

Not a big deal, but something to think about.

[brainman]

On Thursday, 16 April 2015 11:43:46 UTC+10, Keith Randall wrote:

What about timer signals?  ...

We don't have timer signals on windows too. We get around by running an OS timer in a separate special thread.

Alex 

[Russ Cox]

This sounds better, thanks.

I was thinking specifically about the profiler but certainly things like SIGHUP or SIGUSR1 should not randomly go to one side or the other.

Russ

[Srdjan Petrovic]

On Wed, Apr 15, 2015 at 5:40 PM, Russ Cox <r...@golang.org> wrote:

It seems worth a try, but I do expect problems with existing Go programs that link C++ that has constructor initialization invoked by the dynamic loader before the Go binary gets a chance to start. In that case Go currently overrides the C++ handlers, which I think is probably the right thing to do. 

Perhaps the forwarding could be done only in the shared library mode? It seems likely the runtime would know whether it's the main executable or not.

Wow, this is uncanny, here is iant@'s comment on my CL a few days ago:

"If a regular Go program uses cgo and winds up being linked against a C shared library, and the C shared library installs signal handlers in the initialization code, then it seems to me we should chain to those signal handlers when appropriate."

I'm fine either way, to me iant@'s reasoning seems slightly more logical since we'll only forward a signal that occurs outside of Go. Or are you worried that regardless of logic, we shouldn't change the behavior of existing programs?

 

Russ

[Fredrik Ehnbom]

Related: https://github.com/golang/go/issues/7227

[minux]

should the list of signal to be forwarded be OS specific?

I think we'd better forward SIGUSR1 on android (or perhaps better,

don't register Go handler for SIGUSR1 at all.)