[Rd] Could Rstd_Busy do something (src/unix/sys-std.c)?
Simon Urbanek
simon.urbanek at r-project.org
Sat Dec 15 17:09:35 CET 2012
On Dec 15, 2012, at 6:36 AM, Jakson Alves de Aquino wrote:
> Currently the function Rstd_Busy() does nothing (src/unix/sys-std.c):
>
> void attribute_hidden Rstd_Busy(int which)
> {
> }
>
> The function is called through a pointer and R interfaces can change
> this pointer and, thus, use a different function. I don't plan to
> create a whole new interface to R, but I maintain a package whose aim
> is to provide a new feature to R when it's running in a terminal
> emulator on Unix systems:
>
> http://cran.r-project.org/web/packages/setwidth/index.html
>
> The package setwidth updates the value of options("width") whenever R receives
> SIGWINCH signal. The package does not set the value of any interface pointer,
> but it may make R crash if the terminal emulator is resized while R is busy. I
> could avoid the crash if I knew that R is busy at the moment that it receives
> the SIGWINCH. Thus my question is: Could Rstd_Busy() set the value of a
> variable so packages like setwidth could know that R is busy? The function
> could be changed to something like:
>
> void attribute_hidden Rstd_Busy(int which)
> {
> R_is_busy = which;
> }
>
> And the R_is_busy variable could be accessed either directly or through a "get"
> function, like:
>
> int get_busy_state(){
> return R_is_busy;
> }
>
You're looking at the wrong spot - the Busy callback is meant for UI signaling that R may enter a longer time of processing, it is not really an indicator that R is busy - R can be busy even without the busy state being signaled.
But back to your original question - there are a few spots where you can process you request : the most obvious one is in the ReadConsole callback - that callback doesn't return until the user has entered a line - this would be a way to a GUI to handle this. The other way is to register an input handler and signal your FD when you get SIGWINCH, that guarantees that your handler will be called as soon as possible after the signal has arrived - that is probably what you want (see CarbonEL for a simple example how this is used).
Cheers,
Simon
> Thanks!
>
> --
> Jakson Alves de Aquino
> Federal University of Ceará
> Social Sciences Department
> www.lepem.ufc.br/aquino.php
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
More information about the R-devel
mailing list