search

MichaelChirico / r-bugs

A ⚠️read-only⚠️mirror of https://bugs.r-project.org/
20 stars 0 forks source link

[BUGZILLA #15040] tcltk conflicts with mclapply #4628

Closed MichaelChirico closed 4 years ago

MichaelChirico commented 4 years ago

I gather this is not a surprise problem to R core, but it was a surprise to me. I can't find mention of it in your bugzilla, so I've created this new one to put it on the record. And to beg for some expert guidance on our long term future with tcltk.

In Emacs-Ess, some hangs were complained about and Stephen Eglen linked the problem back to the presence of tclk.

Stephen pointed to this older message

https://stat.ethz.ch/pipermail/r-sig-hpc/2009-August/000324.html,

In which it is claimed that this simple R --vanilla session hangs:

library(tcltk) library(multicore) example(mclapply)

Today, on Debian, I've just tested it again and it does hang the R process. Without the tcltk thing, the example runs.

Here's my version info from a session right before I run the example.

sessionInfo()

R version 2.15.1 (2012-06-22) Platform: x86_64-pc-linux-gnu (64-bit)

locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=C LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages: [1] tcltk stats graphics grDevices utils datasets methods [8] base

other attached packages: [1] multicore_0.1-7

I have also tried this with

library(parallel)

and the session still comes to a halt running the example.

To me, this is a huge problem and I wish there were some way I could help to fix it. I'm thinking it should just be more more reason to drop the use of tcltk and try to move R graphics to some less troublesome toolkit. At least, there should be a big warning whenever the R tcltk package loads. Something like

Warning. Warning. tcltk is known to be incompatible with mclapply (and possibly other functions) and we wish you would not load it and re-write your code with GTK2 or WxWindows or .... I

METADATA

MichaelChirico commented 4 years ago

To quote from the docs::

 It is _strongly discouraged_ to use ‘mcfork’ and the higher-level
 functions which rely on it (e.g., ‘mcparallel’, ‘mclapply’ and
 ‘pvec’) in GUI or embedded environments, because it leads to
 several processes sharing the same GUI which will likely cause
 chaos (and possibly crashes).  Child processes should never use
 on-screen graphics devices.  Some precautions have been taken to
 make this usable in ‘R.app’ on Mac OS X, but users of third-party
 front-ends should consult their documentation.

and tcltk is a GUI.

METADATA

MichaelChirico commented 4 years ago

(In reply to comment #1)

To quote from the docs::

It is _strongly discouraged_ to use ‘mcfork’ and the higher-level
functions which rely on it (e.g., ‘mcparallel’, ‘mclapply’ and
‘pvec’) in GUI or embedded environments, because it leads to
several processes sharing the same GUI which will likely cause
chaos (and possibly crashes).  Child processes should never use
on-screen graphics devices.  Some precautions have been taken to
make this usable in ‘R.app’ on Mac OS X, but users of third-party
front-ends should consult their documentation.

and tcltk is a GUI.

Dear Simon:

I think I understand your argument, but I'm surprised by it. Your answer is addressed to programmers who use tcltk, NOT to users who run R. I don't believe the problem is resolved.

If a user runs

library(tcltk) example(mclapply)

I think it is a unreasonable for you to think that the user is supposed to know that tcltk breaks functions that seem NOT to be using tcltk. mclapply is not called from with tcltk, at least from my "user" point of view.

From the point of view of users, tcltk is not really a "3rd party app". Its is provided with R Windows. The tcltk package is provided with the R distribution and it is currently the only GUI framework that is even remotely endorsed by R Core. If a user in Linux runs "install.packages" tcltk loads automatically. It is not considerate to say to that user, "ah, your program broke because tcltk was loaded. That's your fault." And, really, that is what you answered.

I would not mind if R obliterated all traces of tcltk from the main distribution and blocked it from CRAN. Until then, I think it is pretty important to put some stern user-level warning in the tcltk package to explain to users that it has disastrous implications for things they might run that do not obviously involve tcltk.

Of course, I recognize you do need to communicate with programmers and people who write GUIs so that they will get their code right. I don't understand your answer well enough to tell if you mean that tcltk is badly written or that mclapply is badly written, or both. I think the fact that having tcltk loaded will destroy big sets of functions would be very vital news for people who are trying to learn how to write R GUI. That should be in the front page of textbooks like Programming Graphical User Interfaces in R, by John Verzani and Michael Lawrence.

METADATA

MichaelChirico commented 4 years ago

Your report was on Linux and Tcl/Tk it is not a mainstream toolkit anymore (for example, we don't have a single Linux box with tcltk enabled). The behavior will be very OS specific, as it's likely tied to the event loop handling. AFAIR the moment you load tcltk on Linux you start its GUI event loop, so from that moment you are potentially in trouble (and as far as multicore is concerned you are using a GUI). The only binary R distribution that comes with Tcl/Tk by default is on Windows and that doesn't have fork so it's not relevant. I have flagged the PR as wishlist, so if anyone thinks it's worthwhile or someone supplies a patch to make it work, it is very welcome. Until then, my advice is don't do it - others are welcome to comment, though.

METADATA

MichaelChirico commented 4 years ago

To be fair, I believe that most Linux binaries still ship with Tcl/Tk dependencies. Windows is the only distribution where we ship Tcl/Tk and other support libraries in the actual zip files, but that is due to, well, Windows. It is being used on other platforms. There's quite a bit of R code, notably Rcmdr and its plugins, which relies on Tcl/Tk.

I do agree that forking an event loop is a doubleplusungood idea, but I suspect it is not isolated to Tcl/Tk since e.g. X11 events are handled in the same fashion, as are graphics devices, as per Simon's quote. However, it is not an issue that easily resolved; I strongly suspect that it requires a rethinking of the division of labor between the GUI and the computational engine, possibly by going to a multiprocessing client-server-like structure.

A warning is not a bad idea per se, but it could turn out a bit endless to check against all packages which might do something which isn't fork-compatible.

METADATA

MichaelChirico commented 4 years ago

On 06/09/2012 12:39, r-bugs@<::CENSORED -- SEE ORIGINAL ON BUGZILLA::>-project.org wrote:

https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15040

Peter Dalgaard <pd.mes@<::CENSORED -- SEE ORIGINAL ON BUGZILLA::>> changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
CC|                            |pd.mes@<::CENSORED -- SEE ORIGINAL ON BUGZILLA::>

--- Comment #4 from Peter Dalgaard <pd.mes@<::CENSORED -- SEE ORIGINAL ON BUGZILLA::>> 2012-09-06 07:36:55 EDT
---
To be fair, I believe that most Linux binaries still ship with Tcl/Tk
dependencies. Windows is the only distribution where we ship Tcl/Tk and other
support libraries in the actual zip files, but that is due to, well, Windows.
It is being used on other platforms. There's quite a bit of R code, notably
Rcmdr and its plugins, which relies on Tcl/Tk.

I do agree that forking an event loop is a doubleplusungood idea, but I
suspect
it is not isolated to Tcl/Tk since e.g. X11 events are handled in the same
fashion, as are graphics devices, as per Simon's quote. However, it is not an
issue that easily resolved; I strongly suspect that it  requires a rethinking
of the division of labor between the GUI and the computational engine,
possibly
by going to a multiprocessing client-server-like structure.

A warning is not a bad idea per se, but it could turn out a bit endless to
check against all packages which might do something which isn't
fork-compatible.

The quartz() and X11() event loops are (nowadays) disabled in the child, and we could probably disable package tcltk's event loop too. (The key is that there a flag in the executable to say this is a forked child.) But then there is RGtk2's loop ....

Someone who remembers how the tcltk event loop works could try it out.

-- Brian D. Ripley, ripley@<::CENSORED -- SEE ORIGINAL ON BUGZILLA::> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ <CENSORING FROM DETECTED PHONE NUMBER ONWARDS; SEE BUGZILLA>

METADATA