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.
Indeed, the Non-maskable Interrupt. And this continues until the system either is powered off, or a RESET occurs. I do still need to redraw the screen every Frame/VBLANK. The NMI Handler itself has to handle all of this, because its invalid to use dma, except during a VBLANK or FBLANK (which is set on entry to the NMI Handler, and cleared on exit). When the NMI returns, the main "thread" still has nothing to do but spin, waiting for the next one (or something more interesting, like an IRQ or ABORT interrupt).
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.
I never said it was. C++ supports freestanding implementations, where no host os exists.
> > > 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
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals