Menu
▾
▴
[Tcl-bugs] [ tktoolkit-Bugs-749908 ] problems with threaded Tk and multiple interps
|
From: SourceForge.net <no...@so...> - 2005-08-17 13:17:27
|
Bugs item #749908, was opened at 2003-06-06 02:19 Message generated for change (Comment added) made by dkf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=749908&group_id=12997 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 74. Application Embedding Group: current: 8.4.11 Status: Open Resolution: None Priority: 6 Submitted By: Joe Mistachkin (mistachkin) Assigned to: Jeffrey Hobbs (hobbs) Summary: problems with threaded Tk and multiple interps Initial Comment: The platform in question is Windows NT/2000. If I start up tetris.tcl, then close it, then try to run it again in the same interp, I get the usual (expected) error message "can't invoke wm command, app has been destroyed". However, if I then delete the interpreter, create a new one, and attempt to run tetris.tcl, I get: bad screen distance "aaaaaaaaaaaaaaaaaaaaïÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍï0ïD" (default value for "HOME" in widget ".r.board") invoked from within "canvas $widget(board) -width $tetris(width) - height $tetris(height) -bg gray" (procedure "Init" line 85) invoked from within "Init" (in namespace eval "::Tetris" script line 1319) invoked from within "namespace eval Tetris {; variable tetris variable block variable players variable stats variable pmap variable piece variable widget ## VERSION: set..." (file "tetris.tcl" line 25) invoked from within "source "tetris.tcl"" Some digging reveals the offending code may be in tkOldConfig.c. Similar garbage is displayed if you try to re-run the Gem Game. In addition, a panic caused by TlsFree failing results if you attempt to exit the process after creating an interpreter with Tk, delete it, and create another one. This is definately a recent issue as I know I've done this sort of thing with 8.3.x and [i believe] 8.4.x. I cannot imagine how this behavior could be by design. ---------------------------------------------------------------------- >Comment By: Donal K. Fellows (dkf) Date: 2005-08-17 14:17 Message: Logged In: YES user_id=79902 Basically, the patch I did makes all the public functions in tkOldConfig.c treat the Tk_ConfigSpec parameters as 'const' data (unlike previously), which they do by creating per-interpreter copies. The per-interp copies are inherently thread-safe (or at least anything that comes a cropper is going to run into lots of other trouble too) and there is already a defined callback mechanism for ensuring that the per-interp copies get deleted at the right time. The reason for changing tkOldConfig.c as opposed to the clients of that code is that it makes *all* the users of the code (including extensions like BLT, Tix, etc.) safe from thread problems in this area of their code *without* modification. The alternative (making the callers manage per-thread copies of everything) spreads the maintenance effort much wider and is more complexity overall *anyway*. The whole assocData API should be treated as a way of having client code put their own fields in the Interp struct. Tk uses it in a number of places. In theory could use a per-thread copy instead of a per-interp copy, but I do not believe that the extra code (and maintenance complexity) to achieve this is warranted. ---------------------------------------------------------------------- Comment By: Joe Mistachkin (mistachkin) Date: 2005-08-17 09:41 Message: Logged In: YES user_id=113501 Well, I haven't seen dkf's patch for this bug (and the other associated bug 1247919); however, I am somewhat skeptical of the assocData idea. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2005-08-16 17:58 Message: Logged In: YES user_id=72656 What remains outstanding then? Or is a full code review required? ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2005-08-16 15:36 Message: Logged In: YES user_id=79902 My patch has now been backported as well. Note that the other issues in this area (finalization ordering for one) have not been tackled by either patch. But patches to fix these issues should now be much smaller. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2005-08-12 18:22 Message: Logged In: YES user_id=72656 Can the HEAD variant be applied for 8.4 as well? That seems to be the correct solution. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2005-08-12 16:26 Message: Logged In: YES user_id=79902 Fixed in HEAD using a different approach that will work with 3rd party code as well without modifications. Basically, it stores per-interpreter copies of all the Tk_ConfigSpec tables in Tcl's assocData stuff. ---------------------------------------------------------------------- Comment By: Joe Mistachkin (mistachkin) Date: 2005-08-01 03:32 Message: Logged In: YES user_id=113501 This new patch also fixes bug 1247919. These bugs are related because I found one while testing the fix for the other. ---------------------------------------------------------------------- Comment By: Joe Mistachkin (mistachkin) Date: 2005-07-25 11:37 Message: Logged In: YES user_id=113501 Attached patch totally fixes this bug (and 659129) and is fully threadsafe. Please review because after over two years, I would like to get it committed this week. ---------------------------------------------------------------------- Comment By: Joe Mistachkin (mistachkin) Date: 2005-07-25 07:30 Message: Logged In: YES user_id=113501 After doing some research, here is my overall plan to fix this bug: 1. Place all the configSpecs arrays into ThreadSpecificData for their corresponding files. 2. Each file that has a configSpecs array will have static CheckConfigSpecs and FreeConfigSpecsThreadExitProc functions to initialize and finalize their configSpecs array. 3. All places in the same file as the configSpecs array will be modified to use the CheckConfigSpecs function instead of using the static array. 4. All places in the Tk core where configSpecs is used outside of the file where it came from (like the Tk_ItemType structure, which is NOT thread specific) must be modified to call a function that will actually return the appropriate configSpecs for the calling thread. For item #4, I'm thinking about "adapting" the configSpecs pointer in the Tk_ItemType array (inside the Tk core only), to actually be a function pointer with a fixed prototype that will be used to object the configSpecs array. If this field is supposed to be used externally (outside the core), this change would require a TIP. In the future, to avoid similar traps, we need to be very careful about using any kind of static data when that data can be modified (or deleted, in this case) by multiple threads. ---------------------------------------------------------------------- Comment By: Joe Mistachkin (mistachkin) Date: 2005-07-25 06:12 Message: Logged In: YES user_id=113501 This bug still repros in HEAD. I think I'm going to take a crack at fixing it. ---------------------------------------------------------------------- Comment By: Joe Mistachkin (mistachkin) Date: 2004-06-22 12:04 Message: Logged In: YES user_id=113501 Still reproducible in HEAD. Makes Tk unusable in a multiple interp environment. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2003-11-11 19:19 Message: Logged In: YES user_id=72656 This is likely to be addressed in the 8.5 timeframe. ---------------------------------------------------------------------- Comment By: Joe Mistachkin (mistachkin) Date: 2003-11-11 08:04 Message: Logged In: YES user_id=113501 Any chance of this getting fixed? For 8.4.x? For 8.5? ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2003-07-16 23:57 Message: Logged In: YES user_id=72656 This may be related to Tk bug 659129 (Tk_Uids clean up incorrectly w/ threads) ---------------------------------------------------------------------- Comment By: Joe Mistachkin (mistachkin) Date: 2003-06-06 09:18 Message: Logged In: YES user_id=113501 At least one of the defValue fields from the configSpecs array (the one that is causing the error message) is trashed on delete of interp by: MSVCRTD! memset + 67 bytes Tcl_DeleteHashTable(Tcl_HashTable * 0x05840914) line 618 + 19 bytes FreeUidThreadExitProc(void * 0x00000000) line 508 + 19 bytes Tcl_FinalizeThread() line 929 + 12 bytes InterpreterThreadProc(void * 0x04e22c40) line 2750 + 13 bytes MSVCRTD! beginthreadex + 307 bytes KERNEL32! lstrcmpiW + 190 bytes ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=749908&group_id=12997 |