You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I use later in my package to call R from a C++ background thread in a safe way.
From looking in the source code I assume later waits for some regular callbacks and, if the call stack is empty the later code is run.
(Please correct me if these assumptions are wrong)
Does the call stack need to be completely empty for technical reasons or could later run code while R is in a loop or executing other code?
For example: I would like to execute code while R waits for keyboard inputs:
later::later(function() { print("Hello from later") }, 1)
readline("Waiting for keyboard input") # wait for more than 1 sec. then pressing enter
Expected output:
(Text is printed 1 sec after execution, before enter is pressed)
Waiting for keyboard input
[1] "Hello from later"
[1] ""
Actual output:
(Text is printed after enter is pressed)
Waiting for keyboard input
[1] ""
[1] "Hello from later"
Thank you for the quick response. Could you maybe go into more detail why the call stack needs to be empty? Is this a technical limitation or a design decision by later?
Edit: It seems like Rhttpd.c does not check the call stack. Would it be possible to add a priority flag to later which disables the check?
I use later in my package to call R from a C++ background thread in a safe way.
From looking in the source code I assume
later
waits for some regular callbacks and, if the call stack is empty thelater
code is run.(Please correct me if these assumptions are wrong)
Does the call stack need to be completely empty for technical reasons or could
later
run code while R is in a loop or executing other code?For example: I would like to execute code while R waits for keyboard inputs:
Expected output:
(Text is printed 1 sec after execution, before enter is pressed)
Actual output:
(Text is printed after enter is pressed)
Possibly similar issue: #152
The text was updated successfully, but these errors were encountered: