runtime: deliver os/signal notifications under the threads scheduler - #5631
runtime: deliver os/signal notifications under the threads scheduler#5631yohimik wants to merge 1 commit into
Conversation
signal.Notify delivers a signal on hosted linux and macOS only while some other goroutine is in time.Sleep. Both hosts default to -scheduler=threads. A program that installs a handler and then waits on the channel, which is what a command does to stop on SIGINT, waits for ever. The receiving goroutine in os/signal calls signal_recv, which parks itself with task.Pause when nothing is pending. Only checkSignals resumes it, and on the receive path the callers of checkSignals are waitForEvents, the idle hook of the cooperative scheduler, and sleepTicks. With threads there is no scheduler loop, so waitForEvents never runs and only a sleep elsewhere in the program lets a signal through. Give the receiver a wait that works on a thread. signal_recv now blocks on a futex of its own that the handler wakes, with the same 0/1 protocol that the handler already uses on signalFutex. It cannot share signalFutex, because sleepTicks waits on that one too and swaps it back to zero, so a time.Sleep anywhere in the program would take the wakeup of the receiver. The handler only gets an atomic store and a futex wake syscall, which are both safe in a signal handler on an arbitrary thread. The stop-the-world signal of the GC uses a different handler that this does not touch. signalWaitUntilIdle, which signal.Stop and signal.Reset call before they return, had the same problem from the other side. It spun on Gosched, which is a no-op with threads, so it used a core until the receiver emptied the last signal. It now waits on a futex that signal_recv wakes. The cooperative path keeps its behaviour. The two versions live in signal_cooperative.go and signal_threads.go, split on scheduler.threads like the schedulers themselves. testdata/signal.go grows a first phase that waits on the channel and nothing else. Built from the current dev branch on macOS 26.6 arm64 it prints nothing and hangs. With this change it prints the expected output and exits.
545f911 to
369c493
Compare
|
Rebased on dev after the 0.42.0 release. The problem is present in v0.42.0 as |
|
This overlaps with #5530 (open since July), which addresses the same defect: under the threads scheduler, signal delivery only happens while some goroutine happens to be inside The approaches differ enough to be worth comparing side by side before review effort lands on both:
The Flagging so this gets decided once: happy to close #5530 in favor of this one, or rebase mine, whichever direction the maintainers prefer. cc @deadprogram who reviewed #5530. |
|
No problem, close if already done (I asked fable to check if there are any open prs related) |
2 participants
Status: closed in favor of #5530. The implementation and evidence below are retained as a historical record.
runtime: deliver os/signal notifications under the threads scheduler
What this does
signal.Notifydelivers a signal on hosted linux and macOS only while someother goroutine is in
time.Sleep. Both hosts default to-scheduler=threads.A program that installs a handler and then waits on the channel, which is what a
command does to stop on SIGINT, waits for ever.
The receiving goroutine in
os/signalcallssignal_recv, which parks itselfwith
task.Pausewhen nothing is pending. OnlycheckSignalsresumes it, andon the receive path the callers of
checkSignalsarewaitForEvents, the idlehook of the cooperative scheduler, and
sleepTicks. With threads there is noscheduler loop, so
waitForEventsnever runs and only a sleep elsewhere in theprogram lets a signal through. This is why the current
testdata/signal.gopasses. It sleeps for 100 ms in
main.signal_recvnow blocks on a futex of its own that the handler wakes, with thesame 0/1 protocol that the handler already uses on
signalFutex. It cannotshare
signalFutex, becausesleepTickswaits on that one too and swaps itback to zero, so a
time.Sleepanywhere in the program would take the wakeup ofthe receiver. The handler only gets an atomic store and a futex wake syscall,
which are both safe in a signal handler on an arbitrary thread. The
stop-the-world signal of the GC uses a different handler that this does not
touch.
signalWaitUntilIdle, whichsignal.Stopandsignal.Resetcall before theyreturn, had the same problem from the other side. It spun on
Gosched, which isa no-op with threads, so it used a core until the receiver emptied the last
signal. It now waits on a futex that
signal_recvwakes.The two versions live in
src/runtime/signal_cooperative.goandsrc/runtime/signal_threads.go, split onscheduler.threadslike theschedulers themselves.
Evidence
testdata/signal.gogets a first phase that waits on the channel and nothingelse, so no timer and no sleep can carry the delivery. It is already in the
TestBuildhost list, so it runs in the linux and the macOS CI jobs with notest-list change.
Built on macOS 26.6 arm64, default scheduler.
got expected signal/got expected signal/exiting signal program, exit 0A downstream product also ships binaries built with a fork that carries this
change, in the published release dispat v1.4.0.
https://github.com/yohimik/dispat/releases/tag/services%2Fdispat%2Fv1.4.0
Scope and known gaps
-scheduler=tasksfails to link on darwin withduplicate symbol: _tinygo_task_exit, and-scheduler=asyncifyfails withundefined: task.SystemStack. Both failures also happen on the current dev branch withtestdata/print.go, so they are separate and are not addressed here.os/signal.signal_ignoredis still missing, sotinygo test os/signaldoesnot link. That is why the test is a
testdataprogram and not the standardlibrary suite. It can be a follow-up.
Related
This is what a command line program needs for an orderly stop on SIGINT or
SIGTERM. It is one of the pieces that made a real CLI work under TinyGo on
hosted linux and macOS.
Related pull requests
Each open PR in this series has a separate change. A dependency is not a copied commit.
In tinygo-org/net
Full Darwin networking also needs the merged net changes and a later src/net pin update. No upstream merge or current full-suite pass is implied by this list.