[Rd] weird bug with parallel, RSQlite and tcltk

[peter dalgaard]

On Jan 3, 2013, at 10:32 , Karl Forner wrote:

> Hello,
> 
> The point is that I do not use tcltk, it gets loaded probably as a
> dependency of a dependency of a package.
> When I unload it all work perfectly fine. I just found it because one
> of my computer did not have tk8.5 installed, and did not exhibit the
> mentioned bug. So I really think something should be done about this.
> Maybe the "gui loop" should not be run a the the loading of the tcltk
> package, but
> at the first function ran, or something like this.

Doesn't sound doable. It would be tricky to do and wouldn't help in the cases where people actually want to use the GUI - plus, it would leave a time bomb if you directly or indirectly fire up a Tk window (say, the CRAN menu from install.packages()).

More likely, the wisdom of calling R_ProcessEvents and R_PolledEvents in parallel processes should be questioned. I tend to think that they should both be disabled completely conditionally on R_isForkedChild. At least in the Tk loop, some of the events are generated as responses to specific queries, and having one process ask for something and another one handling the reply, leaving the first one waiting indefinitely, is just Not Right.

On the other hand, I'm unsure whether the parent process has its hands free to handle events while a set of parallel processes are in operation. If not, then I suppose that the GUI could get stopped dead in its tracks. 

> 
> As you can see in my example code, the in-memory database is opened in
> the parallel code...
> 
> Best,
> Karl
> 
> On Mon, Dec 31, 2012 at 10:58 PM, Simon Urbanek
> <simon.urbanek at r-project.org> wrote:
>> 
>> On Dec 31, 2012, at 1:08 PM, Karl Forner wrote:
>> 
>>> Hello,
>>> 
>>> I spent a lot of a time on a weird bug, and I just managed to narrow it down.
>>> 
>> 
>> First, tcltk and multicore don't mix well, see the warning in the documentation (it mentions GUIs and AFAIR tcltk fires up a GUI event loop even if you don't actually create GUI elements). Second, using any kind of descriptors in parallel code is asking for trouble since those will be owned by multiple processes. If you use databases files, etc. they must be opened in the parallel code, they cannot be shared by multiple workers. The latter is ok in your code so you're probably bitten by the former.
>> 
>> Cheers,
>> Simon
>> 
>> 
>> 
>>> In parallel code (here with parallel::mclappy, but I got it
>>> doMC/multicore too), if the library(tcltk) is loaded, R hangs when
>>> trying to open a DB connection.
>>> I got the same behaviour on two different computers, one dual-core,
>>> and one 2 xeon quad-core.
>>> 
>>> Here's the code:
>>> 
>>> library(parallel)
>>> library(RSQLite)
>>> library(tcltk)
>>> #unloadNamespace("tcltk")
>>> 
>>> res <- mclapply(1:2, function(x) {
>>>      db <- DBI::dbConnect("SQLite", ":memory:")
>>> }, mc.cores=2)
>>> print("Done")
>>> 
>>> When I execute it (R --vanilla  < test_parallel_db.R), it hangs
>>> forever, and I have to type several times CTRL+C to interrupt it. I
>>> then get this message:
>>> 
>>> Warning messages:
>>> 1: In selectChildren(ac, 1) : error 'Interrupted system call' in select
>>> 2: In selectChildren(ac, 1) : error 'Interrupted system call' in select
>>> 
>>> Then, just remove library(tcltk), or uncomment
>>> unloadNamespace("tcltk"), and it works fine again.
>>> 
>>> I guess there's a bug somewhere, but where exactly ?
>>> 
>>> Best,
>>> 
>>> Karl Forner
>>> 
>>> Further info:
>>> 
>>> 
>>> R version 2.15.1 (2012-06-22) -- "Roasted Marshmallows"
>>> Copyright (C) 2012 The R Foundation for Statistical Computing
>>> ISBN 3-900051-07-0
>>> Platform: x86_64-unknown-linux-gnu (64-bit)
>>> 
>>> ubuntu 12.04 and 12.10
>>> 
>>> ubuntu package tk8.5
>>> 
>>> ______________________________________________
>>> R-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>> 
>>> 
>> 
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Peter Dalgaard, Professor
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd.mes at cbs.dk  Priv: PDalgd at gmail.com