search for: selectchildren

...ion(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 exa...

...rked, the lock will never be released in the child process, leaving it stuck. Depending on how you're running R, it may be threading issues or something else. More information may be obtained by looking at traceback() after you interrupt mclapply() (easy, but low information: did you interrupt selectChildren() or some other function?) and attaching a C debugger to the child process when you become sure it's stuck (hard, requires additional preparation such as installing debugging symbols). -- Best regards, Ivan

...arallel BLAS which doesn't always handle fork() or something. It may be worth disabling BLAS-level parallelism as long as you're already trying to use 100% of your processor by other means. 1) What does traceback() show after you interrupt pbmclapply? Most likely, you would be interrupting selectChildren(), but if not, the problem may lie in a very different place from what I'm expecting. 2) While pbmclapply is hung, without interrupting it, take a look at the state of the system and the processes on it (are you still on RHEL? use `top` or whatever task manager you're comfortable with)....

...[1] TRUE [1] TRUE Error in mcexit(0L) : ignoring SIGPIPE signal [1] TRUE [1] TRUE [1] TRUE until interrupted. Running options(error=traceback) repeat print(forkTimeout({Sys.sleep(1);TRUE}, timeout=3)) results in sporadic messages of the form: Error in mcexit(0L) : ignoring SIGPIPE signal 6: selectChildren(jobs, timeout) 5: parallel::mccollect(child, wait = FALSE, timeout = timeout) at forkTimeout.R#75 4: withCallingHandlers(expr, warning = function(w) invokeRestart("muffleWarning")) 3: suppressWarnings(parallel::mccollect(child, wait = FALSE, timeout = timeout)) at forkTimeout.R#75 2: fork...

...to persist forever until I kill them explicitly. > Is there anything I can do ? > I can reproduce the issue on Debian amd64 Linux and it seems that for some reason an additional wait() is necessary there on 64-bit Linux to get rid of the last child. The easiest work-around is to simply run selectChildren() when you what to get rid of any zombies. I'll need to look at the code to see if there is some clean way to handle this. Thanks, Simon PS: feel free to forward this to the thread you mention below so it gets filed accordingly. > > This user seems to have noticed sth. similar: &gt...

Dear Jeff, There was a problem in LYGH and lapply threw an error, but mclapply got stuck in an infinite loop. The doc for mclapply says that mclapply runs under try() with silent = TRUE. So that means mclapply should run properly, i.e output a try class object and exit. But it didn't. Can you shed some light on why this happened? THanking you, Yours sincerely, AKSHAY M

...rked, the lock will never be released in the child process, leaving it stuck. Depending on how you're running R, it may be threading issues or something else. More information may be obtained by looking at traceback() after you interrupt mclapply() (easy, but low information: did you interrupt selectChildren() or some other function?) and attaching a C debugger to the child process when you become sure it's stuck (hard, requires additional preparation such as installing debugging symbols). -- Best regards, Ivan [[alternative HTML version deleted]]

Dear members, I am using pbmcapply to parellise my code. But the following code doesn't work: > LYG <- pbmclapply(LYGH,FUN = arfima,mc.cores = 2,mc.preschedule = FALSE) | | 0%, ETA NA^ It just hangs. But the