On Windows, call some equivalent to `R_PolledEvents`

[DavisVaughan]

See #1180 for more

On Unix we override R_PolledEvents() with

libr::set(R_PolledEvents, Some(r_polled_events));

We can't do this on Windows, this concept does not exist there.

There are 2 places on a Unix system where R_PolledEvents() is really called from that we are missing right now on Windows:

• R_ProcessEvents() -> R_PolledEvents()`

  • Used in many places, but the main one is from R_CheckUserInterrupt()
  • So on Windows I think our polled events aren't ever running at R_CheckUserInterrupt() time

• R_runHandlers() -> R_PolledEvents()

  • R_runHandlers() is a unix concept as well
  • Sys.sleep() -> Rsleep() -> R_runHandlers() -> R_PolledEvents()
    • But Rsleep() on Unix also calls R_CheckUserInterrupt(), so using R_ProcessEvents() would work here
    • And Rsleep() on Windows directly calls R_ProcessEvents()

I think for the most part this isn't the end of the world. For tasks that typically get run in polled_events() at interrupt time, they instead get run in the main run_event_loop() at idle time.

But we do do this in polled_events() which isn't replicated elsewhere

        if let Some(text) = self.debug_filter.check_timeout() {
            self.emit_stdout(text);
        }

---

We could consider removing our polled_events() hook altogether. If it isn't being invoked on Windows right now, how useful is it really? That would force us to remove interrupt tasks as a concept altogether, something we have been interested in. It would be worth finding a case where interrupt tasks are very useful on Mac that we are currently lacking on Windows before discarding this idea.

If we want to keep interrupt tasks, on both OSes, we have access to hook into R_ProcessEvents():

• Unix: ptr_R_ProcessEvents, settable at any moment
• Windows: Rp->Callback which sets a static ptr_ProcessEvents, settable only at startup

We'd have to reconcile the fact that we can't set Rp->Callback at any moment on windows, meaning RLocalPolledEventsSuspended wouldn't be precisely reproducible for process events, but maybe we could have a global atomic boolean that we flip instead, and our callback would just bail if that is set to false (i.e. suspended).

We also would need to reconcile with the fact that we currently manually call R_ProcessEvents(), and typically we seem to be expecting that tasks dont run at that time (i.e. the comment says we are typically suspended), so that might need some thinking as well

    fn process_idle_events() {
        // Process regular R events. We're normally running with polled
        // events disabled so that won't run here. We also run with
        // interrupts disabled, so on Windows those won't get run here
        // either (i.e. if `UserBreak` is set), but it will reset `UserBreak`
        // so we need to ensure we handle interrupts right before calling
        // this.
        unsafe { R_ProcessEvents() };

[DavisVaughan]

If we do use R_ProcessEvents() then we are going to want to analyze process_idle_events() in its entirety as well

    fn process_idle_events() {
        // Process regular R events. We're normally running with polled
        // events disabled so that won't run here. We also run with
        // interrupts disabled, so on Windows those won't get run here
        // either (i.e. if `UserBreak` is set), but it will reset `UserBreak`
        // so we need to ensure we handle interrupts right before calling
        // this.
        unsafe { R_ProcessEvents() };

        crate::sys::console::run_activity_handlers();

        // Run pending finalizers. We need to do this eagerly as otherwise finalizers
        // might end up being executed on the LSP thread.
        // https://github.com/rstudio/positron/issues/431
        unsafe { R_RunPendingFinalizers() };

        // Check for Positron render requests.
        //
        // TODO: This should move to a spawned task that'd be woken up by
        // incoming messages on plot comms. This way we'll prevent the delays
        // introduced by timeout-based event polling.
        graphics_device::on_process_idle_events();
    }

We think:

• graphics_device::on_process_idle_events() goes away with plot comm improvements
• R_RunPendingFinalizers() could run once at the beginning of each event loop
• run_activity_handlers() may need to stick around and run every 50ms still, we aren't sure yet, but at the very least we could scope this to just this function

We think we still want to run R_ProcessEvents() at idle time, because we think that the other things that it does (like doevent() and R_Tcl_do()) to run at idle time.

But we also want to use R_ProcessEvents() being run at interrupt time as our way to run interrupt tasks.

What that all means is that we probably need to disable interrupt tasks when we run R_ProcessEvents() at idle time, and then reenable them afterwards so they can run at interrupt time.

[lionel-]

oh one update regarding the eager pending finaliser. It was done for posit-dev/positron#431
but then the issue was reopened, and only really closed once we ran R on the main thread. So maybe we can remove it altogether.

Although it's nice in principle to finalise things after a top-level command. We could even run gc to clean things up, potentially.