Overview
Artifact ID: | 53ff16fbd770d850789c73015410303304fc2a8a6144d6cbb6ec9529cb2d593d |
---|---|
Ticket: | c6057948e5f884435ee35517008db0205f286a5e
tsv commands break thread access rules for Tcl values |
User & Date: | dgp 2018-03-29 23:02:20 |
Changes
- assignee changed to: "nobody"
- closer changed to: "nobody"
- cmimetype changed to: "text/plain"
- comment changed to:
Multi-thread access to a Tcl_Obj struct is at best perilous because the Tcl_IncrRefCount and Tcl_DecrRefCount public routines are not routines at all, but macros. And they are macros written with the strong assumption that while they operate the caller has exclusive access to the field. The only safe approach is to follow a strict rule that any Tcl_Obj is accessed by only a single thread that can be said to "own" that value. If you need to pass a value from one thread to another, you need to have the second thread create its own copy of the first, quite possibly limited only to the mechanism of making a full copy of the string rep. These rules are checked by the Tcl core when the --enable-symbols=mem configuration setting is on. Tcl_Obj allocation stores the allocated pointer in a thread-local hash map, and deallocation removes from the same thread-local hash map. Some mismatches (but not all?!?!) are detected with a Tcl_Panic().
- is_private changed to: "0"
- login: "dgp"
- priority changed to: "5 Medium"
- resolution changed to: "None"
- severity changed to: "Critical"
- status changed to: "Open"
- submitter changed to: "dgp"
- subsystem changed to: "80. Thread Package"
- title changed to:
tsv commands break thread access rules for Tcl values
- type changed to: "Bug"