<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 27, 2018 at 12:06 AM, Kevin Ushey <span dir="ltr"><<a href="mailto:kevinushey@gmail.com" target="_blank">kevinushey@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">What environment are you executing this on? (R in terminal, or with a GUI; which OS?)</div></blockquote><div><br></div><div>Here is my session Info: <br></div><div><br></div><div>```<br></div><div>R version 3.4.4 (2018-03-15)<br>Platform: x86_64-pc-linux-gnu (64-bit)<br>Running under: Ubuntu 16.04.4 LTS<br><br>Matrix products: default<br>BLAS: /usr/lib/libblas/libblas.so.3.6.0<br>LAPACK: /usr/lib/lapack/liblapack.so.3.6.0<br><br>locale:<br> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=zh_TW.UTF-8 LC_COLLATE=en_US.UTF-8 <br> [5] LC_MONETARY=zh_TW.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_PAPER=zh_TW.UTF-8 LC_NAME=C <br> [9] LC_ADDRESS=C LC_TELEPHONE=C LC_MEASUREMENT=zh_TW.UTF-8 LC_IDENTIFICATION=C <br><br>attached base packages:<br>[1] stats graphics grDevices utils datasets methods base <br><br>other attached packages:<br>[1] supc_0.2.1<br><br>loaded via a namespace (and not attached):<br>[1] compiler_3.4.4 tools_3.4.4 Rcpp_0.12.17 </div><div>```<br></div><div><br></div><div>And I have tested it in Rstudio and console. Both of them trigger the same error.<br></div><div><br></div><div>I have not tested R 3.5. I can give one tomorrow.<br></div><div></div><div>Maybe it is worth constructing a unit test.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>One thing to be cautious of is that many R APIs in graphical environments will also call for processing of events, and this in turn can also imply a check for, and handling of, interrupts. Rprintf() is in fact one such API (and this is called behind the scenes by Rcout).</div><div><br></div><div>This implies something quite unfortunate: attempts to use any R APIs which call for processing of events within a C++ context can cause a longjmp that bypass C++ destructors and leave you in a bad state.</div><div><br></div><div>Fortunately, things will be better with the newer Rcpp evaluation system from R 3.5 and above, thanks for R_UnwindProtect() and work from Lionel to integrate that with the Rcpp evaluation model. See <a href="https://github.com/RcppCore/Rcpp/pull/789" target="_blank">https://github.com/<wbr>RcppCore/Rcpp/pull/789</a> for some of the details on the initial PR. We're still settling out some final details on the API but once that's ready we'll have some documentation + hopefully an Rcpp gallery example describing its use.</div><div><br></div><div>(We might also consider in Rcpp wrapping our calls to Rprintf() in R_ToplevelExec() and 'catching' and 'rethrowing' interrupts seen, but this might have some unintended side-effects)</div><div><br></div><div>Best,</div><div>Kevin<br><br><div class="gmail_quote"><div><div class="gmail-h5"><div dir="ltr">On Thu, Jul 26, 2018 at 8:18 AM Wush Wu <<a href="mailto:wush978@gmail.com" target="_blank">wush978@gmail.com</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-h5"><div dir="ltr"><div>Hi all,</div><div><br></div><div>I just learned the function `checkUserInterrupt` and played with it in my package today. At first, everything was good. However, I sensed something wrong when I interrupted my function and relaunched it. In my case, the thread number of OpenMP decreased to 1 after an user interruption.<br></div><div><br></div><div>According to the documentation, the `checkUserInterrupt` will throw an exception to trigger the C++ destructors on the stack. However, if I use `Rcout` several times (verbose mode of my function), then it will not throw the exception but leave the function directly.<br></div><div><br></div><div>Here is a toy example to demonstrate: <a href="https://gist.github.com/wush978/36c4e5d8324dd14040eecb4b1dd1c631" target="_blank">https://gist.github.com/<wbr>wush978/<wbr>36c4e5d8324dd14040eecb4b1dd1c6<wbr>31</a> <br></div><div><br></div><div>It uses `Rcout` / `std::cout` as a progressbar and check the user interruption. If the exception is thrown correctly, then a catch clause will handle the exception and write something to the `std::cerr`.<br></div><div><br></div><div>If I turn off the verbose mode, then the `checkUserInterrupt` always throws the exception. <br></div><div><br></div><div>If I turn on the verbose mode and use `jsize` to select the number of dot on the screen, then the `checkUserInterrupt` will exit the function immediately if `jsize` is large. For example, `checkUserInterrupt` throws exception if `jsize = 5` but does not throw if `jsize = 100`.<br></div><div><br></div><div>If I use `std::cout` instead of `Rcpp::Rcout`, then everything goes right again. So, there might be something wrong even if `R_TopLevelExec` is used.<br></div><div><br></div><div>Well, I guess this bug might be hard to debug, but we should let the others aware about this at least, right?</div><div><br></div><div>Best,</div><div>Wush<br></div></div></div></div>
______________________________<wbr>_________________<br>
Rcpp-devel mailing list<br>
<a href="mailto:Rcpp-devel@lists.r-forge.r-project.org" target="_blank">Rcpp-devel@lists.r-forge.r-<wbr>project.org</a><br>
<a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel" rel="noreferrer" target="_blank">https://lists.r-forge.r-<wbr>project.org/cgi-bin/mailman/<wbr>listinfo/rcpp-devel</a></blockquote></div></div></div>
</blockquote></div><br></div></div>