Dear Ivan, REgrets to reply this late... By "holding a lock", you mean a bug in the process right (I am not a computer science guy, excuse my naivete)?
THanking you, Yours sincerely, AKSHAY M KULKARNI ________________________________ From: Ivan Krylov <krylov.r...@gmail.com> Sent: Thursday, May 18, 2023 1:08 PM To: akshay kulkarni <akshay...@hotmail.com> Cc: r-help@r-project.org <r-help@r-project.org> Subject: Re: [R] mclapply enters into an infinite loop.... On Wed, 17 May 2023 13:55:59 +0000 akshay kulkarni <akshay...@hotmail.com> wrote: > 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? What's your sessionInfo()? Are you using a GUI frontend? mclapply() relies on the fork() system call, which is tricky to get right in a process where other threads may exist at the same time: when a process calls fork(), the child process ends up with the same contents of virtual memory but no other threads at all. If a thread was holding a lock when the process was forked, 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]] ______________________________________________ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.