On Sat, May 9, 2020 at 20:03 Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>