[Bioc-devel] Rprintf in a multi-threaded environment
Thanks Martin and Luke, I think the only way to go is to only use the main thread to handle the screen output.
-----Original Message-----
From: Tierney, Luke <luke-tierney at uiowa.edu>
Sent: Wednesday, 30 January 2019 1:16 AM
To: Yang Liao <liao at wehi.edu.au>
Cc: bioc-devel at r-project.org
Subject: Re: [Bioc-devel] Rprintf in a multi-threaded environment
No functions in the R API are safe to call from any thread other than the R main thread.
-- Many may need to allocate from the R heap (more as ALTREP evaolves)
and that is not thread safe;
-- Many (and with some compilation options nearly all) can signal an
error, and the subsequent jump can only work in the main thread.
So: do not make R API calls from any thread other than the main thread. Ever.
[Separate processes as created by approaches in the parallel package
do not have these issues, though simple forking as in multicore can
have other issues as pointed out by Martin Morgan.]
Best,
luke
On Tue, 29 Jan 2019, Yang Liao wrote:
Hi, I'm not sure if some C developers have gone through this problem: it seems that Rprintf cannot work safely in a multi-threaded environment. In particular, if I call Rprintf() from a then-created thread while the stack size checking is enabled (ie the "R_CStackLimit" pointer isn't set to -1), it is very likely to end up with some fatal error messages like: Error: C stack usage 847645293284 is too close to the limit
Error: C stack usage 847336061668 is too close to the limit Error: C stack usage 847666277092 is too close to the limit Error: C stack usage 847346551524 is too close to the limit Error: C stack usage 847367531236 is too close to the limit Error: C stack usage 847357041380 is too close to the limit Error: C stack usage 847378021092 is too close to the limit Error: C stack usage 847655787236 is too close to the limit
, and the R session terminates in a segfault. After I used all means to confirm that there was no memory leakage and the real stack use was minimum, I thought it can only be the Rprintf issue. I then disabled all screen outputs from the then-created threads and the error was gone. It was also reported on stackoverflow: https://stackoverflow.com/questions/50092949/why-does-rcout-and-rprint f-cause-stack-limit-error-when-multithreading I tried using a semaphore to protect all Rprintf calls but it didn't prevent the error. Since my program needs to report some messages from the worker threads (created by the main thread), I wonder if there is a solution to safely do so, or I have to pipe the messages to the main thread, which in turn calls Rprintf? I hope not to change "R_CStackLimit" to disable the stack size checks because it generates a "NOTE" in R check. Cheers, Yang
_______________________________________________
The information in this email is confidential and\ > i...{{dropped:30}}