#1369 Tk_Uids clean up incorrectly w/ threads

[Anonymous]

From Christian Werner (chw ch-werner de)

While playing around with Tk 8.4.1 and multi-threading
on Win32
I observed some strange behaviour w.r.t. Tk_Uids:

1. Tk_ConfigureWidget() converts the name/class/default
values
in the given Tk_ConfigSpec to UIDs.

2. Tk_GetUid() installs a per-thread exit handler
(FreeUidThreadExitProc()) which destroys the per-thread
UID
table (and the UIDs, too) on thread termination, i.e.
after the thread using Tk exited, some Tk_ConfigSpec
fields
point to free'd memory.

3. When Tk is re-animated later (Tk_Init()) in a new
thread,
arbitrary Bad Things happen as consequence to
invalidated UIDs
from point 2.

Questions:

- Is it really necessary to convert name/class/default
values to
UIDs in Tk_ConfigureWidget ?
- Is it really necessary to have a per-thread UID table ?
---
In the meantime I tried to temporarily fix it by:

1. Making dbName/dbClass/defValue fields in
Tk_ConfigSpec
to normal char pointer instead of Tk_Uids
2. Using a mutex locked global (= per process) Uid table
3. Making a temporary copy of the Tk_ConfigSpec array
in
Tk_ConfigureWidget

See the attached patch. However, this isn't perfect since
the
TK_CONFIG_OPTION_SPECIFIED bit is not reflected to
callers
of Tk_ConfigureWidget for threaded builds of Tk.
---
And attached patch.

[Nobody/Anonymous]