Ticket Change Details
Not logged in
Bounty program for improvements to Tcl and certain Tcl packages.
Tcl 2018 Conference, Houston/TX, US, Oct 15-19
Send your abstracts to tclconference@googlegroups.com
or submit via the online form by Aug 20.

Artifact ID: 53ff16fbd770d850789c73015410303304fc2a8a6144d6cbb6ec9529cb2d593d
Ticket: c6057948e5f884435ee35517008db0205f286a5e
tsv commands break thread access rules for Tcl values
User & Date: dgp 2018-03-29 23:02:20

  1. Change assignee to "nobody"
  2. Change closer to "nobody"
  3. Change cmimetype to "text/plain"
  4. Change comment 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().

  5. Change is_private to "0"
  6. Change login to "dgp"
  7. Change priority to "5 Medium"
  8. Change resolution to "None"
  9. Change severity to "Critical"
  10. Change status to "Open"
  11. Change submitter to "dgp"
  12. Change subsystem to "80. Thread Package"
  13. Change title to:

    tsv commands break thread access rules for Tcl values

  14. Change type to "Bug"