emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#41507: closed ([PATCH Shepherd 0/2] Use 'signalfd' on GNU/Linux)


From: GNU bug Tracking System
Subject: bug#41507: closed ([PATCH Shepherd 0/2] Use 'signalfd' on GNU/Linux)
Date: Tue, 26 May 2020 22:15:01 +0000

Your message dated Wed, 27 May 2020 00:13:53 +0200
with message-id <address@hidden>
and subject line Re: [bug#41507] [PATCH Shepherd 2/2] shepherd: Use 'signalfd' 
when possible.
has caused the debbugs.gnu.org bug report #41507,
regarding [PATCH Shepherd 0/2] Use 'signalfd' on GNU/Linux
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden.)


-- 
41507: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=41507
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: [PATCH Shepherd 0/2] Use 'signalfd' on GNU/Linux Date: Sun, 24 May 2020 16:27:00 +0200
Hello!

This patch series allows shepherd to use ‘signalfd’ on GNU/Linux.
It allows us to avoid race conditions related to signal delivery,
which in turn means we can pass an infinite timeout to ‘select’,
and thus increase battery life.

More generally, it’s a way to structure the code around the event
loop.  The next step will be to make the code entirely reactive,
so we can have things like socket activation, being able to start
services that don’t depend on one another concurrently, and all that.
(This is actually also be possible without ‘signalfd’ but it’s more
consistent and robust to have everything visible to ‘select’.)

Thoughts?

I guess the main question is: can it go into 0.8.1, which we outta
release soon due to <https://issues.guix.gnu.org/40981>.  I’d say
“yes”, but I’ll be even more confident if others take a look.  :-)

Ludo’.

Ludovic Courtès (2):
  system: Add support for 'signalfd'.
  shepherd: Use 'signalfd' when possible.

 configure.ac                   | 18 +++++++++
 modules/shepherd.scm           | 73 ++++++++++++++++++++++++++++++----
 modules/shepherd/service.scm   | 19 +++++----
 modules/shepherd/system.scm.in | 65 ++++++++++++++++++++++++++++++
 4 files changed, 161 insertions(+), 14 deletions(-)

-- 
2.26.2




--- End Message ---
--- Begin Message --- Subject: Re: [bug#41507] [PATCH Shepherd 2/2] shepherd: Use 'signalfd' when possible. Date: Wed, 27 May 2020 00:13:53 +0200 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
Hi!

Mathieu Othacehe <address@hidden> skribis:

>> +    (lambda args
>> +      (if (= ENOSYS (system-error-errno args))
>> +          #f
>> +          (apply throw args)))))
>
> Maybe:
>
> (and (= ENOSYS (system-error-errno args))
>      (apply throw args))

It’s not equivalent.  :-)

>> +(define (handle-signal-port port)
>> +  "Read from PORT, a signalfd port, and handle the signal accordingly."
>> +  (let ((signal (consume-signalfd-siginfo port)))
>> +    (cond ((= signal SIGCHLD)
>> +           (handle-SIGCHLD))
>> +          ((= signal SIGINT)
>> +           (catch 'quit
>> +             (lambda ()
>> +               (stop root-service))
>> +             quit-exception-handler))
>
> Maybe we should create a handle-SIGINT, to make sure that the same code
> is shared with the sigaction handler?

Good idea, done!

>> +        (begin
>> +          ;; Unblock any signals that might have been blocked by the parent
>> +          ;; process.
>> +          (unblock-signals (list SIGCHLD SIGINT SIGHUP SIGTERM))
>
> This made me realize that we may want to disable/reset SIGINT and
> SIGHUP, in the same way that we do for SIGTERM? This is not related to
> your patch anyway.

Right, I’ll let you look into it if that’s fine with you.

> You could also extend the comment to say that it is only necessary if
> using the signalfd mechanism (because signals are not blocked
> otherwise).

Done.

I did:

  make dist
  guix build shepherd --with-source=shepherd-0.8.0.tar.gz \
    -s x86_64-linux -s i686-linux -s armhf-linux -s aarch64-linux
  guix build shepherd --with-source=shepherd-0.8.0.tar.gz \
    --target=i586-pc-gnu

and it all passes.

Janneke, could you check that it works on GNU/Hurd?

Ludo’.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]