From: Christian W. <Chr...@t-...> - 2024-09-03 07:22:02
|
Hello all, few days ago an interesting discussion was on c.l.t. regarding Itcl and Tk used to present an Itk button per dynamically created and destroyed thread. It uncovered a long standing bug in Itcl regarding thread safety, which got quickly fixed by sebres. Now for the windowing system(s): it seems that Win32 is ready for this use case, whereas X11 and macos are not. I'm not very familiar and competent with macos, so let's focus on X11: * There are two possible font renderers in the X11 port of Tk: the plain old XDrawString() and libxft using Xrender and freetype. * While the XDrawString() way is as thread safe as the whole Xlib, the libxft is not at all. Maybe you remember that I initially proposed a central mutex for various libxft calls in order to overcome this issue. * The central mutex seems to work but only as long as there's no dynamic regarding opening and closing display connections (which is the essence of the use case discussed on c.l.t.). When display connections are XOpenDisplay()'ed and XCloseDisplay()'ed randomly through the life time of a Tk program I observed very early crashes at various places in Xrender/Xft but not when using plain old XDrawString(). * After days of debugging I found a simple non-solution: on thread exit all X resources pertaining to the Tk applications of the thread are released, but the final XCloseDisplay() is not carried out. Instead the display connection is hold back (parked) on a process wide table to be re-used later. Final XCloseDisplay()s of all display connections are carried out per process exit handler. * Nevertheless, the XSetErrorHandler() is a mess and most likely the final nail in Xlib's coffin, see https://www.remlab.net/op/xlib.shtml so the best option would be to switch everything to XCB. But this is a huuuge undertaking. The result of these findings can be reviewed in this check-in https://www.androwish.org/home/info/9b0450622edec074 in the hope that it is useful for later adoption in Tk > 9.0. Best regards, Christian |