On Friday, 8 May 2020 20:03:22 PDT connor horman via Std-Proposals wrote:
> SNES Game that's finished but needs still draw/redraw stuff. STP will mask
> the NMI from the VBLANK signal, which is how the game knows to load stuff
> into VRAM on the PPU, so it can be sent out on the multiout connector when
> the VBLANK is done.

That counts like doing something other than idling in an infinte loop. Are
those requests handled by interrupts? The proper way of waiting in C++ would
be to sleep on a condition variable or something similar until everything is
done.

Anyway, SNES is not a modern architecture with a real OS these days. The game
itself is basically the operating system, so it goes back to what I said
above: the OS that has finished executing and doesn't know how to turn the
device off.

> > > A further case would be an init process on linux, which cannot terminate
> > > (doing so results in a kernel panic), nor can just call hlt in a loop,
> > > as
> > > that's one way to get a #GP which probably translates to SIGILL.
> >
> > It should call reboot(2). This is not a valid example.
>
> Not if the OS is still running it shouldn't.

Correct, but if the OS is still running it shouldn't do a busy-wait either.
That would add a process competing for 100% CPU usage on your device. So we
conclude that a Linux init must never busy-wait.

> > It can use less resources by calling a function that will sleep forever,
> > like
> > poll() with no timeout and no file descriptors. In any case, I don't know
> > for
> > sure, but I think yield() counts as observable side-effect.
>
> It would still have to be in a loop to prevent spurious wake ups.

Yes, and? What's the problem with a loop on poll()? That counts as I/O /
observable effect.

If you really don't want that, set SA_RESTART on your signals. Just remember
to code your init properly to handle child processes exiting (I think SIG_IGN
SIGCHLD will do that for you).

> This was also just an example of code that may want to spin forever in
> userspace, and can't just hlt.

No, we concluded it wasn't a valid example.

> > Yes, in low-level code. Assembly.
>
> "There is no lower-level language" was one of my main points, and a core
> design principle of C++ if I remember correctly,p.

Reality does not match the theory. If you're writing such low-level code, you
have to write assembly somewhere. The language does not provide library
functions or core language features to manipulate processor data structures
like loading new page tables, executing return-from-interrupts, etc.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel System Software Products