v0.19: port std/os signals #1484

jay · 2026-09-04T21:09:36Z

jay commented

2026-09-04 21:09:36 +00:00

Ports the remaining signal-handling modules to v0.19 under :std/os, including signal, signalfd, signal-handler, and kqueue.

Warning

LLM-assisted with gerbil-mcp

Ports the remaining signal-handling modules to v0.19 under `:std/os`, including `signal`, `signalfd`, `signal-handler`, and `kqueue`. > [!WARNING] > LLM-assisted with `gerbil-mcp`

jay added 2 commits

2026-09-04 21:09:36 +00:00

std: move signal modules into place 94323ded62

std: port signal modules to v0.19 05eb73415a

jay changed title from ~~WIP: v0.19: port std/os signals~~ to v0.19: port std/os signals

2026-09-04 21:29:53 +00:00

jay requested review from Owners

2026-09-04 21:30:02 +00:00

jay force-pushed v0.19-signal from 0583d874a9 to 05eb73415a

2026-09-04 21:34:24 +00:00

Compare

vyzo reviewed

2026-09-05 09:49:40 +00:00

vyzo left a comment

this looks impressively good, but i'll have to do a thorough pass. Spotted an issue at first pass.

Have you run the tests in bsd/darwin? I only have linux boxes so i can't verify those tests.

this looks impressively good, but i'll have to do a thorough pass. Spotted an issue at first pass. Have you run the tests in bsd/darwin? I only have linux boxes so i can't verify those tests.

src/std/os/signal-handler.ss

					
				@ -0,0 +90,4 @@

				          (let (count (device-read device buffer 0 (u8vector-length buffer)))

				            (cond

				             ((fxnegative? count)

				              (device-wait-input! device !NoTimeout))

shouldn't we loop back after device-wait-input! return. missing a (wait-loop) call.

wait-loop is on line 107, outside the cond

jay commented

2026-09-06 04:30:04 +00:00

@vyzo wrote in #1484 (comment):

Have you run the tests in bsd/darwin? I only have linux boxes so i can't verify those tests.

My work computer is a mac, lemme try it there. will report back

@vyzo wrote in https://git.cons.io/mighty-gerbils/gerbil/pulls/1484#issuecomment-2617: > Have you run the tests in bsd/darwin? I only have linux boxes so i can't verify those tests. My work computer is a mac, lemme try it there. will report back

fare approved these changes

2026-09-06 18:53:01 +00:00

Dismissed

fare left a comment

Looks overall good to me, but I have a few concerns that I believe deserve comments in the code at least—if not in this PR, in a quick follow-up.

src/std/os/signal-00-signalfd-test.ss Outdated

					
				@ -0,0 +13,4 @@

				           ./signalfd)

				   (export signalfd-test)

				   (def signalfd-test

My clanker friend GPT 5.6 Sol (High) says:

This test isn't SMP-safe as currently written. sigprocmask only blocks SIGHUP in the calling thread, while kill(getpid(), SIGHUP) may deliver it to any unblocked runtime thread; with the default disposition this can simply kill gxtest. 0583d874a9 seems to have fixed exactly this by blocking before fork/exec, but that commit disappeared in the force-push. Was that intentional? I think we need that setup (or equivalent) back.

My clanker friend GPT 5.6 Sol (High) says: This test isn't SMP-safe as currently written. `sigprocmask` only blocks SIGHUP in the calling thread, while `kill(getpid(), SIGHUP)` may deliver it to any unblocked runtime thread; with the default disposition this can simply kill gxtest. 0583d874a9 seems to have fixed exactly this by blocking before fork/exec, but that commit disappeared in the force-push. Was that intentional? I think we need that setup (or equivalent) back.

src/std/os/signal-handler.ss

					
				@ -0,0 +70,4 @@

				             (:- device OSDevice)

				             write-fd

				             (make-mutex 'signal-handler))

				            (spawn/name 'signal-handler signal-handler-wait self)

Clanker says:

Have we considered the state of this machinery across fork? The child inherits the installed signal dispositions and the pipe FDs, but not this signal-handler thread. So until exec, a registered signal can be caught by ffi_signal_dispatch in the child but can never be dispatched there; a wake byte would also go to the inherited pipe.

Maybe Gambit only gives us a fork→exec window where this is harmless, but it seems worth checking whether fork-and-continue is supported anywhere.

Of course, to make things more interesting, the situation will be different with green threads vs actual SMP. At least a TODO is required. @vyzo care to comment?

Clanker says: > Have we considered the state of this machinery across `fork`? The child inherits the installed signal dispositions and the pipe FDs, but not this signal-handler thread. So until `exec`, a registered signal can be caught by `ffi_signal_dispatch` in the child but can never be dispatched there; a wake byte would also go to the inherited pipe. > > Maybe Gambit only gives us a fork→exec window where this is harmless, but it seems worth checking whether fork-and-continue is supported anywhere. Of course, to make things more interesting, the situation will be different with green threads vs actual SMP. At least a TODO is required. @vyzo care to comment?

i agree, this is problematic. this needs to run on all threads, with on-all-processors that used to be in the now defunct std/misc/threads. I think we need to ressurect this in std/sync/smp and have the on-all-processors procedure there.

we can also do with a TODO here, but i would prefer to resolve this as it is a real issue.

seems we are going to ressurect some more stuff from that module as i am working on porting the remaining on std (std/net/repl uses some). i will put them in std/sync/threads, we can leave a big fat TODO in this pr for now.

src/std/os/signal-handler.ss

					
				@ -0,0 +359,4 @@

				                               (:- (kevent-ident events i) :fixnum))))

				                        (when event-handler

				                          (signal-handler-dispatch

				                           (:- event-handler :procedure)))))

Clanker says (after I corrected its suggestion):

BSD signal multiplicity:

EVFILT_SIGNAL gives us the number of occurrences since the previous kevent in data, but we currently discard that information and invoke the Scheme handler with no indication of multiplicity.

I don't think we necessarily want to call the handler N times: the usual signal-handling protocol is for the handler to treat the signal as a notification and drain whatever underlying state is available, rather than assume one notification corresponds to one event. (SIGCHLD is the obvious example.)

Still, should the event-handler API expose the multiplicity here, or at least should we leave a TODO noting that kqueue gives us information that the current abstraction discards?

Clanker says (after I corrected its suggestion): > BSD signal multiplicity: > > `EVFILT_SIGNAL` gives us the number of occurrences since the previous `kevent` in `data`, but we currently discard that information and invoke the Scheme handler with no indication of multiplicity. > > I don't think we necessarily want to call the handler N times: the usual signal-handling protocol is for the handler to treat the signal as a notification and drain whatever underlying state is available, rather than assume one notification corresponds to one event. (`SIGCHLD` is the obvious example.) > > Still, should the event-handler API expose the multiplicity here, or at least should we leave a `TODO` noting that kqueue gives us information that the current abstraction discards?

src/std/os/signal-handler.ss

					
				@ -0,0 +381,4 @@

				          ((vector-ref handlers signo)

				           (vector-set! handlers signo thunk))

				          (else

				           (ignore-signal! sh signo)

Clanker friend says of FreeBSD (as contrasted to other BSDs):

FreeBSD has a nasty EVFILT_SIGNAL exception here: unlike other signals, SIGCHLD is not reported by kqueue when its disposition is SIG_IGN. Since ignore-signal! is unconditional, add-signal-handler! SIGCHLD won't work on FreeBSD.

This appears inherited from the old implementation rather than introduced here, but this seems like the right time to fix/test it. Perhaps SIGCHLD needs a no-op handler rather than SIG_IGN on FreeBSD.

I'd say this deserves at the very least a "TODO" comment. And I don't think no-op should be it—some kind of wait() and handling of subprocess record would be more appropriate—through a user-overridable hook, I suppose.

Clanker friend says of FreeBSD (as contrasted to other BSDs): > FreeBSD has a nasty `EVFILT_SIGNAL` exception here: unlike other signals, `SIGCHLD` is *not* reported by `kqueue` when its disposition is `SIG_IGN`. Since `ignore-signal!` is unconditional, `add-signal-handler! SIGCHLD` won't work on FreeBSD. > > This appears inherited from the old implementation rather than introduced here, but this seems like the right time to fix/test it. Perhaps `SIGCHLD` needs a no-op handler rather than `SIG_IGN` on FreeBSD. I'd say this deserves at the very least a "TODO" comment. And I don't think no-op should be it—some kind of wait() and handling of subprocess record would be more appropriate—through a user-overridable hook, I suppose.

jay added 1 commit

2026-09-07 18:03:39 +00:00

std: address signal review feedback ac5061588a

Restore inherited-mask signalfd testing: process-directed signals can reach other unblocked native threads. Record the deferred fork, BSD multiplicity, and FreeBSD SIGCHLD concerns requested in review.

jay added 1 commit

2026-09-07 18:03:56 +00:00

Merge branch 'v0.19-staging' into v0.19-signal 6fca9415b6

jay added 1 commit

2026-09-07 18:32:51 +00:00

Merge branch 'v0.19-staging' into v0.19-signal 1286247066

jay requested reviews from fare, vyzo

2026-09-07 18:33:18 +00:00

fare approved these changes

2026-09-07 19:20:24 +00:00

fare merged commit acef95bf60 into v0.19-staging

2026-09-07 19:20:32 +00:00