linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Smith <psmith@gnu.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: David Laight <David.Laight@aculab.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: I disabled more compiler warnings..
Date: Mon, 11 May 2020 16:25:11 -0400	[thread overview]
Message-ID: <7c5cedf6a5f522087b431e0a9f88b6ba66c21405.camel@gnu.org> (raw)
In-Reply-To: <CAHk-=wi=SbaC20nRx5tmAZ2_tOpVOq7469V+KvZU9=4yvfvmnA@mail.gmail.com>

On Mon, 2020-05-11 at 12:33 -0700, Linus Torvalds wrote:
> I wonder if you could just have three different file descriptors:
> 
>  - the "current token file descriptor"
>  - a /dev/null file descriptor
>  - the jobserver pipe file descriptor. This is left blocking.

If I'm understanding your suggestion correctly, this is pretty much how
it worked originally.  Except I didn't use a /dev/null file descriptor:
I dup the jobserver FD, read() the dup, and then in the signal handler
I _closed_ the dup.

So, I can tell what happened by whether the read() returns EINTR vs.
EBADF.

This is still how things work on systems without pselect() support.

There's a blog page I wrote about this many (er... MANY) years ago:

http://make.mad-scientist.net/papers/jobserver-implementation/

You can skip the blather at the top: search down to "Then it gets
ugly..." and check the algorithm there to see if that's what you had in
mind.


The problem is that SA_RESTART works well in Linux but is not always
reliable on other OS's, and it's not always possible to catch EINTR
everywhere (for example, in third party libraries like libintl) so you
can't always automatically restart from a SIGCHLD.

See this bug reported on OS X for example:
  https://savannah.gnu.org/bugs/?func=detailitem&item_id=46261


But, the issue I have now is not related to SIGCHLD, it's related to
SIGINT/SIGTERM etc. handling.  Today, GNU make calls its die() function
directly from the SIGINT signal handler, and die() does A LOT of very
signal-unsafe stuff.  Gross, but it's worked like that for 30 years.

My idea was that since GNU make already uses an EINTRLOOP() macro to
check EINTR returns from system calls and restart, I would have the
SIGINT handler just set a variable, then install into the EINTRLOOP
macro a check of that variable, which would let me transition from
signal handler to user-space without dropping checks all over the code
(at least, not visibly :)).  Maybe I'd check directly in a few places,
where we may go for some time without a system call.

That worked but I do have to contend with the same issue as the
jobserver: any time I need to wait for something I have a race between
the last time I checked for an interrupt and the wait operation.

I have had to put this aside for a bit, so I haven't decided how to
address it but I'm sure it's doable.  The issue with GNU make is it has
to be as portable as possible: make is a foundational tool for any sort
of system bootstrap.  Of course, we could just not support parallel
builds on insufficient systems but...

If people feel this isn't an appropriate topic for lkml, I invite
anyone interested parties to post to bug-make@gnu.org :).


  reply	other threads:[~2020-05-11 20:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-10 19:33 I disabled more compiler warnings Linus Torvalds
2020-05-11  7:43 ` David Laight
2020-05-11 17:41   ` Linus Torvalds
2020-05-11 17:58     ` Paul Smith
2020-05-11 19:33       ` Linus Torvalds
2020-05-11 20:25         ` Paul Smith [this message]
2020-05-11 21:09       ` David Laight
2020-05-12  7:55         ` David Laight
2020-05-12 14:35           ` Paul Smith
2020-05-12 15:04             ` David Laight
2020-05-12 16:55               ` Paul Smith
2020-05-13  8:21                 ` David Laight
2020-05-13 15:32                   ` Paul Smith
2020-05-13 15:53                     ` David Laight
2020-05-13 16:06                       ` Paul Smith
2020-05-11  9:03 ` Arnd Bergmann
2020-05-11 11:11   ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7c5cedf6a5f522087b431e0a9f88b6ba66c21405.camel@gnu.org \
    --to=psmith@gnu.org \
    --cc=David.Laight@aculab.com \
    --cc=arnd@arndb.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).