I don't think we're going to fix this before 4.3.3. Given that it has gone unnoticed since June 2022 (yes '22) and that tampering in this area has a history of popping up complications in other areas, I think we should leave it alone until 4.4.0.
(I see that Ivan and Tomas has been on the issue since I started writing, but the above probably still holds true.) - Peter D. > On 21 Feb 2024, at 08:01 , webmail.gandi.net <phgrosj...@sciviews.org> wrote: > > Thank you, Ivan for this investigation. I inspected the R changes file > (https://cran.r-project.org/doc/manuals/r-devel/NEWS.html) and found nothing > about this. I should inspect the sources too! > > It could possibly break other Tcl/Tk related stuff. The doc about > Tcl_ServiceAll and Tcl_DoOneEvent is confusing. On one hand, it says when Tcl > is used from an external program, Tcl_ServiceAll should be used in its event > loop instead of Tcl_DoOneEvent (and the change in the latest R versions goes > in that direction). But in the other hand, it is indicated that > Tcl_ServiceAll does not always handle all Tcl events and extra Tcl_DoOneEvent > should be called in this case. I think we spotted one case where > Tcl_ServiceAll is not doing its job correctly. There may be others. > > Since the {tcltk} package was working fine with "while > (Tcl_DoOneEvent(TCL_DONT_WAIT) && max_ev) max_ev—;", unless there is a clear > performance enhancement with "while (i-- && Tcl_ServiceAll())", it would > perhaps be wise to revert this back. > > Indeed, when I use this on the server side with R 4.3.2: > > library(tcltk) > cmd <- r"( > proc accept {chan addr port} { ;# Make a proc to accept connections > puts "$addr:$port says [gets $chan]" ;# Receive a string > puts $chan goodbye ;# Send a string > close $chan ;# Close the socket (automatically > flushes) > } ;# > socket -server accept 12345 ;# Create a server socket)" > .Tcl(cmd) > .Tcl("vwait myvar") > > It works again as expected. And vwait is known to call Tcl_DoOneEvent. Of > course, in this case, R is blocked and waits for the `myvar` variable on the > Tcl side. Anyway, the problem seems to be really in Tcl_ServiceAll not > catching all Tcl events. > > All the best, > > Philippe > > ..............................................<°}))><........ > ) ) ) ) ) > ( ( ( ( ( Prof. Philippe Grosjean > ) ) ) ) ) > ( ( ( ( ( Numerical Ecology > ) ) ) ) ) Mons University, Belgium > ( ( ( ( ( > .............................................................. > >> Le 20 févr. 2024 à 17:13, Ivan Krylov via R-devel <r-devel@r-project.org> a >> écrit : >> >> В Tue, 20 Feb 2024 12:27:35 +0100 >> "webmail.gandi.net" <phgrosj...@sciviews.org> пишет: >> >>> When R process #1 is R 4.2.3, it works as expected (whatever version >>> of R #2). When R process #1 is R 4.3.2, nothing is sent or received >>> through the socket apparently, but no error is issued and process #2 >>> seems to be able to connect to the socket. >> >> The difference is related to the change in >> src/library/tcltk/src/tcltk_unix.c. >> >> In R-4.2.1, the function static void TclSpinLoop(void *data) says: >> >> int max_ev = 100; >> /* Tcl_ServiceAll is not enough here, for reasons that escape me */ >> while (Tcl_DoOneEvent(TCL_DONT_WAIT) && max_ev) max_ev--; >> >> In R-devel, the function instead says: >> >> int i = R_TCL_SPIN_MAX; >> while (i-- && Tcl_ServiceAll()) >> ; >> >> Manually calling Tcl_DoOneEvent(0) from the debugger at this point >> makes the Tcl code respond to the connection. Tcl_ServiceAll() seems to >> be still not enough. I'll try reading Tcl documentation to investigate >> this further. >> >> -- >> Best regards, >> Ivan >> >> ______________________________________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel@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 Office: A 4.23 Email: pd....@cbs.dk Priv: pda...@gmail.com ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
