# config

name: css
value:
  /* General settings for the entire page */
  html {
    min-height: 100%;
  }
  body {
    margin: 0ex 1ex;
    padding: 0px;
    background-color: white;
    color: #333;
    font-family: Verdana, sans-serif;
    font-size: 0.8em;
  }

  /* The project logo in the upper left-hand corner of each page */
  div.logo {
    display: table-cell;
    text-align: right;
    vertical-align: bottom;
    font-weight: normal;
  }

  /* Widths */
  div.header, div.mainmenu, div.submenu, div.content, div.footer {
    max-width: 900px;
    margin: auto;
    padding: 3px 20px 3px 20px;
    clear: both;
  }

  /* The page title at the top of each page */
  div.title {
    display: table-cell;
    padding-left: 10px;
    font-size: 2em;
    margin: 10px 0 10px -20px;
    vertical-align: bottom;
    text-align: left;
    width: 80%;
    font-family: Verdana, sans-serif;
    font-weight: bold;
    color: #558195;
    text-shadow: 0px 2px 2px #999999;
  }

  /* The login status message in the top right-hand corner */
  div.status {
    display: table-cell;
    text-align: right;
    vertical-align: bottom;
    color: #333;
    margin-right: -20px;
  }

  /* The main menu bar that appears at the top of the page beneath
   ** the header */
  div.mainmenu {
    text-align: center;
    color: white;
    -moz-border-top-right-radius: 5px;
    -moz-border-top-left-radius: 5px;
    -webkit-border-top-right-radius: 5px;
    -webkit-border-top-left-radius: 5px;
    -border-top-right-radius: 5px;
    -border-top-left-radius: 5px;
    border-top-left-radius: 5px;
    border-top-right-radius: 5px;
    vertical-align: middle;
    padding-top: 8px;
    padding-bottom: 8px;
    background-color: #446979;
    background: -webkit-gradient(linear,left bottom,left top, color-stop(0.02, rgb(51,81,94)),  color-stop(0.76, rgb(85,129,149)));
    background: -moz-linear-gradient(center bottom,rgb(51,81,94) 2%, rgb(85,129,149) 76%);
    -webkit-box-shadow: 0px 3px 4px #333333;
    -moz-box-shadow: 0px 3px 4px #333333;
    box-shadow: 0px 3px 4px #333333;
  }

  /* The submenu bar that *sometimes* appears below the main menu */
  div.submenu {
    padding-top:10px;
    padding-bottom:0;
    text-align: right;
    color: #000;
    background-color: #fff;
    height: 1.5em;
    vertical-align:middle;
    -webkit-box-shadow: 0px 3px 4px #999;
    -moz-box-shadow: 0px 3px 4px #999;
    box-shadow: 0px 3px 4px #999;
  }
  div.mainmenu a, div.mainmenu a:visited {
    padding: 3px 10px 3px 10px;
    color: white;
    text-decoration: none;
  }
  div.submenu a, div.submenu a:visited, a.button,
  div.sectionmenu>a.button:link, div.sectinmenu>a.button:visited {
    padding: 2px 8px;
    color: #000;
    font-family: Arial;
    text-decoration: none;
    margin:auto;
    -webkit-border-radius: 5px;
    -moz-border-radius: 5px;
    border-radius: 5px;
    background: -webkit-gradient(linear,left bottom, left top, color-stop(0, rgb(184,184,184)), color-stop(0.75, rgb(214,214,214)));
    background: -moz-linear-gradient(center bottom, rgb(184,184,184) 0%, rgb(214,214,214) 75%);
    background-color: #e0e0e0 ;
    text-shadow: 0px -1px 0px #eee;
    filter: dropshadow(color=#eeeeee, offx=0, offy=-1);
    border: 1px solid #000;
  }

  div.mainmenu a:hover {
    color: #000;
    background-color: white;
  }

  div.submenu a:hover, div.sectionmenu>a.button:hover {
    background: -webkit-gradient(linear,left bottom, left top, color-stop(0, rgb(214,214,214)), color-stop(0.75, rgb(184,184,184)));
    background: -moz-linear-gradient(center bottom, rgb(214,214,214) 0%, rgb(184,184,184) 75%);
    background-color: #c0c0c0 ;
  }

  /* All page content from the bottom of the menu or submenu down to
   ** the footer */
  div.content {
    background-color: #fff;
    -webkit-box-shadow: 0px 3px 4px #999;
    -moz-box-shadow: 0px 3px 4px #999;
    box-shadow: 0px 3px 4px #999;
    -moz-border-bottom-right-radius: 5px;
    -moz-border-bottom-left-radius: 5px;
    -webkit-border-bottom-right-radius: 5px;
    -webkit-border-bottom-left-radius: 5px;
    border-bottom-right-radius: 5px;
    border-bottom-left-radius: 5px;
    padding-bottom: 1em;
    min-height:40%;
  }


  /* Some pages have section dividers */
  div.section {
    margin-bottom: 0.5em;
    margin-top: 1em;
    margin-right: auto;

    padding: 1px 1px 1px 1px;
    font-size: 1.2em;
    font-weight: bold;

    text-align: center;
    color: white;

    -webkit-border-radius: 5px;
    -moz-border-radius: 5px;
    border-radius: 5px;

    background-color: #446979;
    background: -webkit-gradient(linear,left bottom,left top, color-stop(0.02, rgb(51,81,94)),  color-stop(0.76, rgb(85,129,149)));
    background: -moz-linear-gradient(center bottom,rgb(51,81,94) 2%, rgb(85,129,149) 76%);

    -webkit-box-shadow: 0px 3px 4px #333333;
    -moz-box-shadow: 0px 3px 4px #333333;
    box-shadow: 0px 3px 4px #333333;
  }

  /* The "Date" that occurs on the left hand side of timelines */
  div.divider {
    font-size: 1.2em;
    font-family: Georgia, serif;
    font-weight: bold;
    margin-top: 1em;
    white-space: nowrap;
  }

  /* The footer at the very bottom of the page */
  div.footer {
    font-size: 0.9em;
    text-align: right;
    margin-bottom: 1em;
    color: #666;
  }

  /* Hyperlink colors in the footer */
  div.footer a { color: white; }
  div.footer a:link { color: white; }
  div.footer a:visited { color: white; }
  div.footer a:hover { background-color: white; color: #558195; }

  /* <verbatim> blocks */
  pre.verbatim, blockquote pre {
    font-family: Dejavu Sans Mono, Monaco, Lucida Console, monospace;
    background-color: #f3f3f3;
    padding: 0.5em;
    white-space: pre-wrap;
  }

  blockquote pre {
    border: 1px #000 dashed;
  }

  /* The label/value pairs on (for example) the ci page */
  table.label-value th {
    vertical-align: top;
    text-align: right;
    padding: 0.2ex 2ex;
  }


  table.report {
    border-collapse:collapse;
    border: 1px solid #999;
    margin: 1em 0 1em 0;
  }

  table.report tr th {
    padding: 3px 5px;
    text-transform : capitalize;
  }

  table.report tr td {
    padding: 3px 5px;
  }

  textarea {
    font-size: 1em;
  }

  /* Side-by-side diff */
  table.sbsdiff {
    background-color: white;
    font-family: Dejavu Sans Mono, Monaco, Lucida Console, monospace;
    font-size: 6pt;
    border-collapse:collapse;
    width: 98%;
    border: 1px #000 dashed;
    margin-left: auto;
    margin-right: auto;
  }

  table.sbsdiff th.diffhdr {
    border-bottom: dotted;
    border-width: 1px;
  }

  table.sbsdiff tr td {
    padding-left: 3px;
    padding-right: 3px;
    margin: 0px;
    vertical-align: top;
    white-space: pre-wrap;
  }

  table.sbsdiff tr td.lineno {
    text-align: right;
    /* border-bottom: 1px solid rgb(220, 220, 220); */
  }

  table.sbsdiff tr td.srcline {
    /* max-width: 400px; */
    /* Note: May partially hide long lines without whitespaces */
    /* overflow: hidden; */
    /* border-bottom: 1px solid rgb(220, 220, 220); */
  }

  table.sbsdiff tr td.meta {
    background-color: rgb(170, 160, 255);
    padding-top: 0.25em;
    padding-bottom: 0.25em;
    text-align: center;
    -moz-border-radius: 5px;
    -moz-border-radius: 5px;
    -webkit-border-radius: 5px;
    -webkit-border-radius: 5px;
    -border-radius: 5px;
    -border-radius: 5px;
    border-radius: 5px;
    border-radius: 5px;
  }

  table.sbsdiff tr td.added {
    background-color: rgb(180, 250, 180);
    /* border-bottom: 1px solid rgb(160, 230, 160); */
  }

  table.sbsdiff tr td.removed {
    background-color: rgb(250, 130, 130);
    /* border-bottom: 1px solid rgb(230, 110, 110); */
  }

  table.sbsdiff tr td.changed {
    background-color: rgb(210, 210, 200);
    /* border-bottom: 1px solid rgb(190, 190, 180); */
  }


name: header
value:
  <html>
  <head>
  <base href="$baseurl/$current_page" />
  <title>$<project_name>: $<title></title>
  <link rel="alternate" type="application/rss+xml" title="RSS Feed"
        href="$home/timeline.rss">
  <link rel="stylesheet" href="$home/style.css?black2" type="text/css"
        media="screen">
  </head>
  <body>
  <div class="header">
    <div class="logo">
      <img src="$home/logo" alt="logo">
      <br /><nobr>$<project_name></nobr>
    </div>
    <div class="title">$<title></div>
    <div class="status"><nobr><th1>
       if {[info exists login]} {
         puts "Logged in as $login"
       } else {
         puts "Not logged in"
       }
    </th1></nobr></div>
  </div>
  <div class="mainmenu">
  <th1>
  html "<a href='$home$index_page'>Home</a>\n"
  if {[anycap jor]} {
    html "<a href='$home/timeline'>Timeline</a>\n"
  }
  if {[hascap oh]} {
    html "<a href='$home/dir?ci=tip'>Files</a>\n"
  }
  if {[hascap o]} {
    html "<a href='$home/brlist'>Branches</a>\n"
    html "<a href='$home/taglist'>Tags</a>\n"
  }
  if {[hascap r]} {
    html "<a href='$home/reportlist'>Tickets</a>\n"
  }
  if {[hascap j]} {
    html "<a href='$home/wiki'>Wiki</a>\n"
  }
  if {[hascap s]} {
    html "<a href='$home/setup'>Admin</a>\n"
  } elseif {[hascap a]} {
    html "<a href='$home/setup_ulist'>Users</a>\n"
  }
  if {[info exists login]} {
    html "<a href='$home/login'>Logout</a>\n"
  } else {
    html "<a href='$home/login'>Login</a>\n"
  }
  </th1></div>
  <div id="container">


# reportfmt

title: All Tickets
cols:
  #ffffff Key:
  #f2dcdc Active
  #e8e8e8 Review
  #cfe8bd Fixed
  #bde5d6 Tested
  #cacae5 Deferred
  #c8c8c8 Closed

sqlcode:
  SELECT
    CASE WHEN status IN ('Open','Verified') THEN '#f2dcdc'
         WHEN status='Review' THEN '#e8e8e8'
         WHEN status='Fixed' THEN '#cfe8bd'
         WHEN status='Tested' THEN '#bde5d6'
         WHEN status='Deferred' THEN '#cacae5'
         ELSE '#c8c8c8' END AS 'bgcolor',
    substr(tkt_uuid,1,10) AS '#',
    datetime(tkt_mtime) AS 'mtime',
    type,
    status,
    subsystem,
    title
  FROM ticket


# event

type: ci
user: welch
comment:
  Moved these into their own "vc" directory.  These are not used for
  the standard TEA builds, but might be useful to others.


type: ci
user: welch
comment:
  Added Tcl_CreateThreadType and TCL_RETURN_THREAD_TYPE
  macros for declaring the NewThread callback proc.


type: ci
user: kupries
comment:
  2000-05-04  Andreas Kupries <a.kupries@westend.com>

  	* Overall changes:
  	  (1) Added joinable threads.
  	  (2) Added transfer of channels between threads.

  	* generic/threadCmd.c: Added functions Thread_Join and
  	  ThreadJoinObjCmd.

  	  Extended function ThreadCreateObjCmd to handle a
  	  -joinable flag.

  	  Fixed bug in Thread_Create, the argument 'stacksize' was not
  	  used.

  	  Removed declaration of ThreadObjCmd, which was not used anywhere
  	  else in the code.

  	  Added functions Thread_Transfer, ThreadTransferEventProc and
  	  ThreadTransferObjCmd. Extended behaviour of ThreadDeleteEvent
  	  and ThreadExitProc to deal with the new class of events.

  	  Changed usage of ckfree to the more canonical Tcl_Free. Same for
  	  ckalloc and Tcl_Alloc.

  	* Makefile.in: Fixed bug with regard to the installation of
  	  documentation.

  	* doc/thread.*: Added documentation of create -joinable,
  	  thread::join and thread::transfer.

  	* tests/thread.test: Added tests for joining of threads and moving
  	  channels between threads.


type: ci
user: kupries
comment:
  2000-05-09 Andreas Kupries  <a.kupries@westend.com>

  	* tests/thread.test: Removed dependency on aclocals.m4. Using a
  	  real temporary file now, as created by a call to
  	  tcltest::makeFile.


type: ci
user: zoran
comment:
     Summary of changes (zoran@munich.com)

     * Added threadSpCmd.c file with implementation of "thread::mutex"
       and "thread::cond" commands. Documentation and tests are still
       pending.

     * Added threadSvCmd.c file with implementation of "thread::sv_*"
       family of commands modeled after AOLserver nsv_* ones.
       Documentation and tests are still pending.

     * fixed Makefile.in for the two above

     * Added "thread::exists" command to threadCmd.c.
       Updated docs for this new command.

     * Moved most of internal functions in threadCmd.c to statics,
       except the Thread*ObjCmd()

     * Changed behaviour of "thread::exit". It now simply flips the
       bit to signal thread stuck in thread::wait to gracefuly exit.
       As a consequence, command now does not trigger error on thread exit.
       ThreadWait() and ThreadStop() are newly added to support this.
       Also the ThreadSpecificData has one more integer: "stopped"

     * Replaced ref's to obsolete Tcl_GlobalEval() with new Tcl_EvalEx()

     * fixed broken 'thread::create -joinable script';
       was missing initialization of script variable


type: ci
user: davidg
comment:
  2000-08-09  David Gravereaux <davygrvy@ajubasolutions.com>

  	* win/vc/thread.rc: swapped "Scriptics Corp" for "Ajuba
  	Solutions"

  	* win/vc/config.vc:
  	* win/vc/makefile.vc: cleaned-up old cruft.  Added new files
  	from Zoran's patches.  made swapping to MSDev 6.0 easier.
  	Removed the '!if $(_NMAKE_VER) > 162' test for 2 reasons.

  	1) batchmode inference rules are valid since MSDev 5.0 and
  	the core can't be built with less.  So don't bother testing.

  	2) nmake.exe that comes with MSDev 6.0 has a bug with the
  	meaning of that macro and MS decided to use a string instead
  	breaking the integer comparison test.


type: ci
user: davidg
comment:
  Removed the event loop sinking because this extension is only responsible for it's own events in the event loop.


type: ci
user: davidg
comment:
  2000-08-20  David Gravereaux <davygrvy@ajubasolutions.com>

  	* win/vc/config.vc:
  	* win/vc/makefile.vc:
  	* win/vc/README.txt:
  	* win/vc/thread.dsp:  A near top down rewrite that adds
  	four more build configurations.  See README.TXT for the
  	details.

  	* win/vc/.cvsignore:  A few more glob patterns added to match
  	the new build directories.


type: ci
user: davidg
comment:
  OUTDIR macro was being defined on spawning nmake under VC6.  This was having a negative change on the makefile.


type: ci
user: davidg
comment:
  2000-08-21  David Gravereaux <davygrvy@ajubasolutions.com>

  	* generic/threadCmds.c (Thread_Init): Added logic to enable
  	thread::join and thread::transfer when loaded into an 8.4+ core.
  	We don't don't want a seg fault when the Stubs tables don't
  	match.


type: ci
user: davidg
comment:
  2000-08-29  David Gravereaux <davygrvy@ajubasolutions.com>

  	* generic/threadCmd.c (NewThread): Tcl_Init return value wasn't
  	being verified.  Added a check and failure logic to fall-out.
  	[Bug: 5301]


type: ci
user: zoran
comment:
  2000-10-16  Zoran Vasiljevic <zoran@munich.com>

          * generic/threadSvCmd.c ThreadSvUnsetObjCmd(): deadlocked.
          Forgot to release shared-array lock which resulted in
          deadlock after first successful unset of the variable.


type: ci
user: zoran
comment:
  Please ignore the 1.4 checkin. It contained a bug introduced by the deadlock
  fix. This is now corrected. Sorry for inconvenience.


type: ci
user: davidg
comment:
  2000-10-26  David Gravereaux <davygrvy@ajubasolutions.com>

  	* generic/thread.h:
  	* win/vc/config.vc:
  	* win/vc/makefile.vc:
  	* win/vc/thread.dsp: upped version numbers to 2.2 along with adding
  	a new macro (THREAD_VERSION_SUBSET83) defining the version when
  	loaded into an 8.3 core.  Which happens to be "2.1.1" at this time.

  	* generic/threadCmd.c (Thread_Init): Added logic to allow setting
  	the package version at runtime to "2.2" when compiled against 8.4
  	and loaded into 8.4.  When compiled against 8.4, yet loaded into
  	8.3, thread::join and thread::transfer are not added to the interp
  	and the package version is set to "2.1.1" instead from the single
  	binary.  [ie. multiple interfaces in one binary]  When compiled
  	against 8.3, thread::join and thread::transfer are non-existant and
  	the package version is always "2.1.1" to maintain a consistent
  	interface in all combinations (as per discussions with Don Porter).


type: ci
user: davidg
comment:
  2000-11-02  David Gravereaux <davygrvy@ajubasolutions.com>

  	* generic/threadCmd.c (NewThread): Added logic to test for a
  	working Tcl_Init() based on the core version at runtime and ignore
  	its failure in versions 8.3.[1,2] and 8.4a1.  [BUG: 5301]


type: ci
user: davygrvy
comment:
  Added the EXTERN macro for the prototype of Thread_Init which is more
  standard than using DLLEXPORT directly.


type: ci
user: davygrvy
comment:
  2001-04-26  David Gravereaux <davygrvy@pobox.com>

  	* generic/threadCmd.c (ThreadEventProc): ThreadErrorProc now
  	supported in asyncronous sends when Tcl_Eval returns other than
  	TCL_OK.  It silently failed prior to this.


type: ci
user: davygrvy
comment:
  	* win/vc/makefile.vc:
  	* win/vc/thread.dsp: Change NODEBUG macro to be DEBUG instead.
  	Double negatives give me a headache.  DEBUG=1 makes more sense
  	to me than NODEBUG=0.  Not that I didn't think you wouldn't have
  	disagreed it was confusing, no?


type: ci
user: davygrvy
comment:
  	* doc/thread.n:
  	* tests/thread.test: Replaced thread::exit with thread::unwind and
  	documented the change and clarified the subtleties.


type: ci
user: davygrvy
comment:
  	==== INTERFACE CHANGE ====
  	* generic/threadCmd.c:
  	* generic/thread.h: thread::exit renamed to thread::unwind. The
  	name of 'exit' is misleading.  An exit implies an unconditional
  	return.  But there are conditions.  'unwind' describes with more
  	clarity what's happening to the prior thread::wait.  For example:

  	  # parent thread
  	  set T [thread::create {source worker.tcl}]
  	  ....
  	  thread::send -async $T doStuff
  	  ....
  	  thread::send -async $T doStuff
  	  ....
  	  thread::send -async $T thread::unwind

  	  # worker.tcl
  	  proc init    {} {#do initialization}
  	  proc cleanup {} {#do cleanup}
  	  proc doStuff {} {#the work}
  	  init
  	  thread::wait
  	  cleanup

  	When worker.tcl is sourced, the execution stops at thread::wait and
  	the event loop is entered.  When thread::unwind is sent to the worker,
  	thread::wait falls-out and cleanup is called.  The condition for
  	thread::unwind to cause an exit is determined by the script.  If
  	thread::wait was the last Tcl command in the script, yes the thread
  	will exit.  But if thread::wait is not the last, the execution of the
  	script is just continued.  Hence, the name change to clarify this fact.

  	Package version has not been changed.  There hasn't been an official
  	release of 2.2, so it stays.


type: ci
user: davygrvy
comment:
  	* generic/threadCmd.c (NewThread): removed the previous addition of
  	Tcl_FinalizeThread.  Tcl_ExitThread calls it anyways (my mistake).
  	The resource leak was in the core.  See ->
  	http://sourceforge.net/tracker/?func=detail&atid=110894&aid=419683&group_id=10894
  	for the fix.  That patch is pending approval.

  	To acheive the same behavior of emptying the event loop the way
  	thread::wait used to work, use the following:
  		set T [thread::create {thread::unwind; update}]


type: ci
user: davygrvy
comment:
  	* generic/thread.h:
  	* win/vc/makefile.vc:
  	* win/vc/thread.rc:
  	* win/vc/pkg.vc (new): Moved version numbers from the header file.  It isn't
  	an export API or anything.  Moved version numbers to the build files.  I'll
  	modify configure.in and makefile.in a little later.


type: ci
user: davygrvy
comment:
  	* generic/thread.h:
  	* generic/threadCmd.c:  Re-added original implimentation of [thread::exit].
  	for `emergency use only`.  You have been warned ;)


type: ci
user: davygrvy
comment:
  	* generic/thread.h (deleted):
  	* generic/tclThread.h (new):
  	* generic/threadCmd.c:  decided to change the name of 'thread.h' to
  	'tclThread.h', per request.


type: ci
user: davygrvy
comment:
  	* configure.in:
  	* configure:
  	* win/pkg.vc:  Upped version numbers to 2.3 and 2.1.3 because I just cut
  	a release.


type: ci
user: davygrvy
comment:
  	* configure.in:
  	* configure:
  	* win/vc/thread.dsp:
  	* win/vc/pkg.vc:  Upped version numbers to 2.3 and 2.1.3 because I just cut
  	a release.


type: ci
user: vasiljevic
comment:
  Added guessing files. I wonder how anybody succeeded to compile
  the extension sucessfully without those ?


type: ci
user: vasiljevic
comment:
  Added as the part of upcoming 2.4. Those are implementing almost
  complete list command interface to thread shared variables.


type: ci
user: vasiljevic
comment:
  Totally revamped thread shared variable interface. Now use tsv::
  namespace instead of thread::sv_*. It also stores objects instead
  of strings in the shared memory (improved performace on large
  memory-resident shared datastructures.)


type: ci
user: vasiljevic
comment:
  Extended thread::send to allow asynchronous backfiring of scripts.
  Removed thread::kill until settle on the correct behaviour.


type: ci
user: vasiljevic
comment:
  Added missing parts for thread shared variables.
  Added missing parts for sync primitives.
  Corrected thread::errorproc (was totally out of date)
  Added thread::send modifications (optional varname).


type: ci
user: vasiljevic
comment:
  Preparing the move to 2.4.
  cygwin build not tested yet.
  vc++ build not modified. Will leave it to David.


type: ci
user: vasiljevic
comment:
  The older style of thread::sv_* commands is now activated in addition
  to the new style tsv::*. If you want to force the old interface alone,
  comment-out the OLD_COMPAT define at the top of the file


type: ci
user: vasiljevic
comment:
  * generic/threadCmd.c: fixed multiple async reporting of error events
  (thanks Jean-Luc Fontaine for the tip)


type: ci
user: vasiljevic
comment:
  * generic/threadCmd.c: fixed address od the target interpreter when
  doing the callback async script processing. All messages went to the
  main interpreter instead of the selected interpreter, causing process
  to hung when posting callbacks to more that one interp at the same time.
  (thanks Jean-Luc Fontaine for the tip)


type: ci
user: davygrvy
comment:
  Idea for how to do a thread::kill without Tcl_CreateThread saving the handle.
  This can only work on Win2K.  Maybe WinXP, too, dunno.  Code path is
  turned off, so I don't unstablize the HEAD.


type: ci
user: davygrvy
comment:
  A small 'const' qualifier change.  It's a bit more wordy now, but reads a
  little clearer to me.  Unscambling pointer math gives me a headache and
  combined with a cast tends to be dangerous.


type: ci
user: vasiljevic
comment:
  Added facility to hide certain shared array names using HIDE_DOTNAMES.
  Turned on for AOLServer builds per default.


type: ci
user: hobbs
comment:
  	* generic/tclThread.h:
  	* generic/threadCmd.c: added stub voodoo magic to allow building
  	against Tcl 8.3 and still get all the 8.4+ functionality when later
  	loaded into an 8.4+ interp.


type: ci
user: hobbs
comment:
  	* tclconfig/tcl.m4,install-sh (new):
  	* config/* (removed):
  	* aclocal.m4:
  	* configure:
  	* configure.in:
  	* Makefile.in: Updated build system to use tclconfig (TEA 2002)
  	structure.


type: ci
user: hobbs
comment:
  	* Makefile.in (TCLSH_PROG): moved and updated env var definitions
  	to have tclsh work from build dir.  Removed TCL_EXTRA_CFLAGS,
  	TCL_LD_FLAGS, TCL_SHLIB_LD_LIBS, TCL_DBGX, TCL_STUB_LIB_FILE,
  	TCL_STUB_LIB_SPEC as they aren't needed (configure acquires all
  	that info for us).  TCL_LIBS is also not needed, but left in as a
  	reference to the libs Tcl used.


type: ci
user: hobbs
comment:
  	* configure: regen based on updated tclconfig/tcl.m4
  	* configure.in: moved the SHLIB_LD_LIBS magic into
  	tclconfig/tcl.m4 and noted where users can modify (SHLIB_LD_)LIBS.


type: ci
user: hobbs
comment:
  	* configure:
  	* configure.in: BUILD_${PACKAGE} had to be static BUILD_thread in
  	AC_DEFINE because autoconf wasn't substituting ${PACKAGE}.


type: ci
user: hobbs
comment:
  	* Makefile.in (install-lib-binaries): ensure that binary files are
  	installed with executable bit set (use INSTALL_PROGRAM)


type: ci
user: hobbs
comment:
  	* Makefile.in: improved use of DESTDIR in install targets.
  	Removed need for installdirs target.
  	Broke TCLSH_PROG into TCLSH_ENV and TCLSH_PROG with TCLSH var and
  	added comments about TCLSH_ENV.
  	Added default shell and gdb targets.


type: ci
user: hobbs
comment:
  	* configure:
  	* configure.in: updated to new TEA base that: prefixes all macros
  	with TEA_* instead of SC_*; adds TEA_PREFIX, which defaults the
  	prefix and exec_prefix values to what Tcl used; adds
  	TEA_SETUP_COMPILER, which handles basic compiler / support program
  	checks and simplifies the configure.in.  Turn on --enable-threads
  	by default and do sanity checking as well.


type: ci
user: vasiljevic
comment:
  * generic/threadCmd.c: fixed processing of -eventmark. We now
  properly wait for target thread to catch up with processing events.

  CVS ----------------------------------------------------------------------


type: ci
user: vasiljevic
comment:
  Force-initialize new tcl object in LocateContainer() if one cannot be
  found. Without that, some upper-level code wrongly tried to convert
  the (possible invalid) object type, resulting in memory trashing and
  eventually core dumps.


type: ci
user: vasiljevic
comment:
  Fixed some function parameters where Sun's CC was barfing. Strangely,
  the GNU gcc was perfectly satisfied with those ...


type: ci
user: vasiljevic
comment:
  Added some guarding Tcl_ResetResult calls before each
  Tcl_SetXXObj(Tcl_GetObjResult(..) ...) since the object left in
  interp result *may* be shared under circumstances.


type: ci
user: vasiljevic
comment:
  Newly generated configure (autoconf 2.52).
  modified install-doc target in Makefile to install man documentation
  from the doc/man directory (the new home for nroff docs)


type: ci
user: vasiljevic
comment:
  Removed some extra Tcl_ResetResult since it was breaking reporting of
  errorCode and errorInfo variables


type: ci
user: vasiljevic
comment:
  Moved platform specific build stuff from the top-level README to
  the appropriated win/ and unix/ README file.


type: ci
user: mdejong
comment:
  	* README: Fix typo.
  	* doc/man/thread.n: Note that thread::join and
  	thread::transfer are only available with Tcl 8.4.


type: ci
user: vasiljevic
comment:
  fixed "tsv::lpush" to correctly make a copy
  of the object pushed into the list in shared array element


type: ci
user: vasiljevic
comment:
  Fixed Sv_DuplicateObj to properly invalidate duped object string rep
  after successfully duplicating the internal rep.


type: ci
user: hobbs
comment:
  	* configure:
  	* configure.in: move the CFLAGS definition into TEA_ENABLE_SHARED
  	and make it pick up the env CFLAGS at configure time.


type: ci
user: vasiljevic
comment:
  Fixed ListRemoveInner() to recognize
  and ignore already removed tsd thread structures.
  Fixed some invalid TCL_OK returns which masked serious errors.


type: ci
user: vasiljevic
comment:
  Added more macros for locking/unlocking buckets. This was necessary for
  the new tsv::eval mechanism.


type: ci
user: vasiljevic
comment:
  Added first working implementation of the thread pool.
  Tested and verified with purify but no field tests yet.


type: ci
user: vasiljevic
comment:
  Added thread-pool related exports.
  Added SpliceIn and SpliceOut macros for fiddling with linked lists.


type: ci
user: vasiljevic
comment:
  Rewritten with partial event loop processing. Now only the poster
  does not block the event loop. Worker threads are never stuck in
  the event loop; they just wait on the condition variable.
  Alsom idletimer is still not implemented. Lack of Tcl API support
  makes it little bit more complex.


type: ci
user: vasiljevic
comment:
  Added hand-crafted timeout for worker threads. This should be fixed
  when Tcl API gets a Tcl_ConditionWait which returns the cause the
  function has exited.


type: ci
user: vasiljevic
comment:
  Many cosmetic changes in comments. Also, improved error reporting
  in case when the Tcl interpreter cannot be created in the worker thread.


type: ci
user: vasiljevic
comment:
  Fixed memory leak when posting detached jobs.
  Also, removed Tcl_GetTime in favour of the compatibility implementation.


type: ci
user: mdejong
comment:
  	* generic/threadCmd.c (ThreadSendObjCmd):
  	The thread::send command was not working
  	under Win32 because threads that had an id
  	that was a negative number were generating
  	a usage error in the thread::send command.
  	* tests/thread.test: Add test for negative
  	number as thread id.


type: ci
user: vasiljevic
comment:
  Fixed ThreadSetResult to correctly initialize all elements of the
  result structure received from the caller.


type: ci
user: vasiljevic
comment:
  Fixed ListRemoveInner to unconditionaly reset the head of threads
  linked list when the last thread exits.


type: ci
user: vasiljevic
comment:
  Fixed object copy code for generic objects and list object.
  In some cases, we've missed to properly copy list objects
  with zero elements. Also, with 8.4.2, there are some new
  issues fixed concerning path objects.


type: ci
user: vasiljevic
comment:
  Improved calling of exit handlers. We now always supply clientData
  even if we do not use it. This is because some Tcl internal calls
  test the clientdata if avoid calling the callback if clientData is NULL.


type: ci
user: vasiljevic
comment:
  Removed checking of stopped flag during walk of the list of active threads.
  This solves some subtle thread reservation problems with threads marked to
  unwind on error.


type: ci
user: vasiljevic
comment:
  Fixed bug with NULL tsdPTr introduced in ThreadSend by the
  last checkin. Please consider the previous version unusable.


type: ci
user: vasiljevic
comment:
  Added quick fix for autoconf issues related to $srcdir and building
  of the package from the top-level directory instead of unix/win subdir.
  Thanks to Mo DeJong for the fix.


type: ci
user: vasiljevic
comment:
  Added keyed-list implementation borrwoed from the TclX package.
  We made some slight modifications and additions to be able to
  make the implementation stand-alone (exist w/o Tclx) and to
  be able to plugin into our private deep object copier.


type: ci
user: vasiljevic
comment:
  Added persistent store implementation for shared variables. We now have
  a plugin architecture so people may extend with custom-made persistency
  (for example in SQL databases). A working example of GNU gdbm wrapper
  is supplied.


type: ci
user: vasiljevic
comment:
  Adjusted for conditional compilation with gdbm persistent store wrapper.
  Added new files to the make script.


type: ci
user: vasiljevic
comment:
  Regenrated configure script. Modified aolserver.m4 not to compile
  the library as bundle but as a regular shared lib instead.


type: ci
user: vasiljevic
comment:
  Added implementation of the thread::broadcast command.
  This is actually only the convenience wrapper for something that
  may be achieved from the Tcl level by using already existing
  thread::send, thread::id and thread::names commands.
  What the heck.


type: ci
user: vasiljevic
comment:
  Mark all threads created by the package to distinguish them from other
  "foreign" threads created by some other source. This mainly includes
  threads created by the AOLserver when running as AOLserver module.


type: ci
user: vasiljevic
comment:
  Fixed mutex release (was deadlocking) in ThreadSend when refusing to
  send message to the foreign thread


type: ci
user: vasiljevic
comment:
  ThreadList and ThreadExistsInner hide (i.e. do not report) foreign
  threads, like for example, those created by AOLserver


type: ci
user: vasiljevic
comment:
  Removed the concept of foreign threads; still have to find the way
  to avoid broadcasting non-package created threads (like in aolserver)


type: ci
user: vasiljevic
comment:
  Check if we are running at least in 8.3 core or newer.
  If not, simply return w/o loading the package. This fixes behaviour
  of being in the package path of an pre-8 shell.


type: ci
user: vasiljevic
comment:
  Do automatic "package require Ttrace" during ttrace::eval when
  executing the thread::broadcast command. This saves us of explicitily
  doing this command at thread creation.


type: ci
user: vasiljevic
comment:
  Added thanksgiving comment to Jeffrey Hobbs for doing the stubs-voodoo
  so we're able to link with various Tcl versions.


type: ci
user: vasiljevic
comment:
  Rewritten handling of thread handles as passed to Tcl.
  Instead of casting Tcl_ThreadId to unsigned int, which brought some
  problems on Cray machines, we're now generating opaque string-based
  handles and match them to Tcl_ThreadId internally.


type: ci
user: vasiljevic
comment:
  Improved behaviour when destroying locked mutexes and locking the
  same mutex twice from the same thread. In both cases we throw
  Tcl error instead of coring the process or deadlocking the
  (naive) application.


type: ci
user: vasiljevic
comment:
  Corrected namespace prefix for AOLserver 4.x or higher,
  since namespaced commands are now supported.


type: ci
user: vasiljevic
comment:
  Adjusted to fix some package loading issues on AOLserver 4.x.
  Revamped pool and thread handles to match tpool<number> and tid<number>
  respectively. This should correct issues with handles found on Crays.


type: ci
user: vasiljevic
comment:
  Revamped thread and tpool handles once more, after correcting the
  real cause of bad thread handles on some 64-bit machines in Tcl core.


type: ci
user: andreas_kupries
comment:
  	* generic/threadCmd.c (ThreadErrorProc): Added code to explicitly
  	  initialize the field 'interp' in ThreadSendData. This was ok
  	  (NULL) for a regular build, but when build with symbols the
  	  guard pattern forced a crash in test thread-16.2.

  	* tests/thread.test: Duplicate test id thread-16.1 renamed to
  	  thread-16.2.


type: ci
user: andreas_kupries
comment:
  	* generic/threadSvCmd.c: Added a prototype for
  	  SvObjDispatchObjCmd. Prevented compilation of debug variant on
  	  Windows due to warning as error.

  	* tests/thread.test: Added more tests transfering channels between
  	  threads for in-core drivers.


type: ci
user: andreas_kupries
comment:
  	* tests/thread.test: Added two tests checking the working of
  	  fileevents after a pipe channel has been transfered. The second
  	  has to fail for any core where TIP #218 is not applied, because
  	  the incoming alert is directed to the wrong thread for event
  	  processing.


type: ci
user: vasiljevic
comment:
  All tests regarding channel transfer between threads are now skipped
  for Windows until the core handles this correctly


type: ci
user: vasiljevic
comment:
  o. Adjusted for TEA3 and rebuild with autoconf 2.59
  o. Removed extra handling for Tcl 8.3
     tests/thread.tcl: since we do not support 8.3 any more
  o. Updated docs for the 2.6 release


type: ci
user: vasiljevic
comment:
  changed ttrace::addtrace: it now recognises if the tracing is enabled and
  activates the tracer procedure immediately.
  Added ttrace::isenabled: can be called to check wether the tracing is
  enabled or not.


type: ci
user: vasiljevic
comment:
  Fixed Tcl Bug #1095370. The -minworkers value is now honoured when
  a idle worker exits due to the -idletime timer expiry.


type: ci
user: vasiljevic
comment:
  Fixed Sv_PutContainer which released the container lock too early
  resulting in possible access to already freed container and thus
  to process exitus.


type: ci
user: vasiljevic
comment:
  The ttrace::enable can be called recursively.
  Improved script generation for namespaced variables.
  The overloaded [info] now does the right thing when called on procedures
  which were still not loaded from the ttrace store.


type: ci
user: hobbs
comment:
  	* Makefile.in (AR): use @AR@
  	(TCLSH_ENV): add TCL_THREAD_LIBRARY var
  	* pkgIndex.tcl.in: grok TCL_THREAD_LIBRARY var


type: ci
user: vasiljevic
comment:
  Reverted some temporary changes which do not belong there and were used
  for some internal testing (go tchecked in by mistake)


type: ci
user: mdejong
comment:
  	* Makefile.in: Subst TCLSH_PROG as SYSTEM_TCLSH
  	and subst BUILD_TCLSH and BUILD_TCLSH_PROG.
  	* configure: Regen.
  	* configure.in: Invoke TEA_BUILD_TCLSH from
  	tcl.m4 to correctly determine BUILD_TCLSH.


type: ci
user: mdejong
comment:
  	* Makefile.in: Remove SYSTEM_TCLSH and any
  	code that tries to run tclsh at build time
  	aside from running the test cases.
  	* configure: Regen.
  	* configure.in: Remove calls to TEA_BUILD_TCLSH
  	and TEA_BUILD_WISH since these were removed
  	from tcl.m4. This fixes up the build when
  	--with-tcl indicates either a build dir or
  	and install dir.


type: ci
user: vasiljevic
comment:
  ThreadDetach sets the both source and target thread ID's for the
  detached channel to zero, thus signalizing the cleanup code to
  leave the channel in the list when the thread who detached it exits.


type: ci
user: vasiljevic
comment:
  Added ThreadCutChannel utility proc to cut out the channel from
  thread/interp and clean pending channel events from the event queue.


type: ci
user: vasiljevic
comment:
  Revamped handling because of the deep
  race condition which resulted in
  deadlocks when using exclusive mutexes.


type: ci
user: vasiljevic
comment:
  Fixed race condition when testing constraints
  (mutex being locked by the caller thread) when
  waiting on the condition variable. Also, fixed
  exclusive mutex ownership and usage counting.


type: ci
user: hobbs
comment:
  	* generic/threadPoolCmd.c (AppExitHandler): fix teardown to
  	destruct pool list correctly. [Bug 1427570]


type: ci
user: vasiljevic
comment:
  SvIncrObjCmd now implicitly creates shared array and variable and
  initializes it to zero if the variable and/or array is not found.


type: ci
user: vasiljevic
comment:
  For AOLserver module builds, skip calling Tcl_PkgRreqiure and just
  shortcut to Thread_Init as we not like to load ttrace there by default.


type: ci
user: vasiljevic
comment:
  Added ThreadInit and modifed Thread_Init to call it before
  declaring the package loaded. The ThreadInit is now used to
  initalize C-package only w/o making the package "loaded"
  so the subsequent "package require Thread" done from the Tcl
  level will finish and completely load the package in the
  interpreter.


type: ci
user: vasiljevic
comment:
  lib/ttrace.tcl: Spliced version numbering of the
  Ttrace package to the version of the Thread package
  because of the weirdness of the Tcl package loading
  mechanism. Also, the broadcast script used within
  the ttrace::eval now explicitly loads Ttrace package
  in every broadcasted thread.


type: ci
user: vasiljevic
comment:
  Automatically call "ttrace::update" when ttrace package is loaded.
  This simplifies handling during the new thread creation.


type: ci
user: vasiljevic
comment:
  Uses package name again to construct names of the helper proc so we do
  not inadvertently overwrite some other user procedures when loading
  the package.


type: ci
user: vasiljevic
comment:
  Fixed Sp_ReadWriteMutexRLock() to check existence of sole writer
  by checking the mutex lockcount to be negative


type: ci
user: vasiljevic
comment:
  Fixed memory leak when registering Gdbm store handler. We registered
  the handler every time the module was initialized. Now we
  do it only for the first initialization.


type: ci
user: patthoyts
comment:
  	* win/vc/rules.vc:     Updated the nmake build system to match
  	* win/vc/nmakehlp.c:   current 8.5. (support for non-intel build
  	* win/vc/makefile.vc:  and recent versions of msvc compiler)
  	* win/thread.rc:       Fixed line endings.


type: ci
user: vasiljevic
comment:
  generic/threadSpCmd.h: Added one cond variable per
  sync bucket to wait for item deletion.

  generic/threadSpCmd.c: Threads that want to delete
  any sync primitive now wait properly until the last
  thread that references the primitive detaches.

  Fixed (broken) reference counting of items.

  Fixed wrong release of an condition variable that is
  about to be time-waited.


type: ci
user: vasiljevic
comment:
  RemoveAnyItem plugs the item out of the hash-table before releasing
  the bucket mutex while waiting on the item to be free for deletion.


type: ci
user: vasiljevic
comment:
  generic/threadPool.c: fixed race condition when
  creating minworkers worker thread upfront.
  Failure to create one results in partial pool teardown.
  Fix for Bug # 2005794.


type: ci
user: hobbs
comment:
  	* generic/threadCmd.c (ThreadCutChannel): fix const warning
  	(ThreadSend): safely set interp result object [Bug #1988779]


type: ci
user: hobbs
comment:
  	* generic/threadSvCmd.c: Handle TIP#336 addition of API to access
  	* generic/threadSpCmd.c: interp->errorLine


type: ci
user: ferrieux
comment:
   Reorder things in RemoveMutex and RemoveCondv [Bugs 2511424,2511408]; fix a Put* leak in an error path of rwmutexes [Bug 2511420].


type: ci
user: ferrieux
comment:
  Constify Tcl_ObjGetType return values to get rid of const warnings; #if 0 of SvFinalize which is unused.


type: ci
user: nijtmans
ecomment:
  Silence gcc warning: dereferencing type-punned
  pointer will break strict-aliasing rules
  Regenerated configure script using latest TEA

comment:
  Silence gcc warning: dereferencing type-punned
  pointer will break strict-aliasing rules
  Regenerated configure script using latest TEA


type: ci
user: vasiljevic
comment:
  * generic/threadCmd.c: serialize Tcl_CreateInterp()
  as it is thread-unsafe (indirectly modifies global
  variables w/o protecting locks).


type: ci
user: andreas_kupries
comment:
  	* generic/threadSpCmd.c (ThreadMutexObjCmd, ThreadRWMutexObjCmd):
  	[Bug 3007426]: Dropped trailing commas in enum definitions which
  	choked the strictly C89 AIX compiler.


type: ci
user: andreas_kupries
comment:
  	* pkgIndex.tcl.in: Fixed procedure collisions for Thread package
  	by inlining the load command into the ifneeded script, as is
  	standard for most binary packages. Tweaked the procedure for
  	Ttrace a bit, as the result of [info commands] is a list, and
  	using ::apply when possible. A named procedure is only a fallback.


type: ci
user: dkf
comment:
  	* lib/ttrace.tcl: [Bug 3033206]: Be careful with variables outside of
  	procedures; Tcl's variable resolution rules can jump in if a variable
  	is not declared, which can be at best surprising.
  	Also rewrote the namespace serialization code to be more robust.


type: ci
user: andreas_kupries
comment:
  	* lib/ttrace.tcl (_serializensp, _serializeproc): Fixed typos
  	  which smashed namespace name and opening brace of a script
  	  together, leading to a syntax error for 'namespace eval' and
  	  preventing the use of package Ttrace.


type: ci
user: dkf
comment:
  	* doc/tpool.man, doc/tsv.man: Remove spaces in titledesc declaration;
  	doctools currently does not like it at all when generating correct
  	nroff output.


type: ci
user: vasiljevic
comment:
          * generic/threadCmd.c: Initialize tsdPtr->interp to NULL immediately after
          releasing the interp on thread-exit that should hopefully resolve the
          Tcl Bug #3026061

          * generic/threadCmd.c: Removed safe-init so safe-interps should not be
          able to run thread commands directly.

          * lib/ttrace.tcl: Changed version to 2.6.7 to be in sync with main pkg.

          * configure.in: Bumped version to 2.6.7 and autoconf'ed.


type: ci
user: vasiljevic
comment:
  * generic/configure      Regenrated for TEA 3.9. Bumped version string
  * generic/configiue.in   in all relevant files to 2.6.7  and autoconf'ed.
  * win/vc/pkg.vc


type: ci
user: dgp
comment:
          * Makefile.in:          Revised the `make dist` target so that the
          * win/README.txt:       files under thread/win/vc in CVS are copied to
          * win/vc/makefile.vc:   thread/win in the release, where tcl/pkgs/
          * win/vc/thread_win.dsp:        expects to find them.

          * configure:    autoconf-2.59


type: ci
bgcolor: #f0f080
user: dgp
comment:
  New branch "finalize" where the attempts to finalize the Thread package
  are re-enabled and extended.  Meant to be used in memory leak testing and
  similar debugging scenarios.  Not committed to trunk since comments indicate
  only "the brave" would attempt such an unsolvable problem.


type: ci
user: mistachkin
comment:
  Support asynchronous script cancellation, per TIP #285 (i.e. thread::cancel).  Necessary to replace use of testthread::cancel in the Tcl 8.6 test suite.


type: ci
user: mistachkin
comment:
  Update all remaining versions to 2.7b1. For [thread::cancel], avoid creating a new Tcl_Obj when the default script cancellation result is desired. Stop using -debug:full as it causes an error with the MSVC10 compiler.


type: ci
user: mistachkin
comment:
  The [thread::wait] command must cooperate with the interpreter resource limiting (TIP #143) and asynchronous script cancellation (TIP #285) functionality, when available.


type: ci
user: mistachkin
comment:
  The [thread::wait] command should use the TCL_CANCEL_UNWIND flag when calling Tcl_Canceled because it manages its own event processing loop.  Also, if the event processing loop is terminated due to a script in progress being canceled or exceeding a runtime limit, the registered error script should be evaluated, if any.


type: ci
user: mistachkin
comment:
  Refactor ThreadEventProc to make sure all paths out of the function call Tcl_Release on the necessary Tcl interpreters. Also, call ThreadErrorProc consistently whenever the return code is not TCL_OK (i.e. do not check for it to be equal to TCL_ERROR).


type: ci
user: mistachkin
comment:
  Correct check for current thread in the ThreadReserve function [Bug 3411244].  Correct the order for releasing the interpreter and freeing memory, see check-in [6067508840].


type: ci
bgcolor: #000000
user: jan.nijtmans
comment:
  No longer depend on tcl_platform(threaded) variable starting with Tcl 8.6, since it's always compiled threaded


type: g
user: dgp
comment:
  Edit [241dbe3c53647f3f]: Move to branch [/timeline?r=mistake&nd&dp=241dbe3c53647f3f | mistake]. Change background color to "#000000".


type: g
user: dgp
comment:
  Edit [db1b6eda66d29b7e]: Move to branch [/timeline?r=mistake&nd&dp=db1b6eda66d29b7e | mistake]. Change background color to "#000000".


type: ci
user: andreask
comment:
  Regenerated configure with ac 2.59, using newest tcl.m4. Fixed win* SEH, EXCEPTION_DISPOSITION tests which are gcc-only.


type: ci
user: dgp
comment:
  Eliminate some tricky finalization problems by converting the SpBucket arrays
  from dynamic storage to static storage so they no longer need to be finalized.
  Since they have fixed size of NUMSPBUCKETS, I don't see any strong reason not
  to do this.


type: ci
user: zoran
comment:
  generic/threadCmd.c: Fixed leaking callback data in ThreadSend()
  plus some minor cosmetic changes (tx to Gustaf Neumann).


type: ci
user: zoran
comment:
  Removed extra clbk free in ThreadSend as it may be a double-free.
  The clbk data, if present, is fed as a regular work to the 
  originator thread and is freed there, so freeing it again may
  cause trouble.


type: g
user: jan.nijtmans
comment:
  Edit [26b072f1615f8f32]: Move to branch [/timeline?r=mistake&nd&dp=26b072f1615f8f32 | mistake]. Change background color to "#000000".


type: g
user: jan.nijtmans
comment:
  Edit [b1d8aa9c2ff83175]: Move to branch [/timeline?r=thread-2-6-branch&nd&dp=b1d8aa9c2ff83175 | thread-2-6-branch].


type: ci
user: jan.nijtmans
comment:
  (Unofficial) variant of Thread 2.7, which works with Tcl 8.5+.
  As soon as Thread 2.7 is final, it will work with 8.4 as well.


type: ci
user: jan.nijtmans
comment:
  Fixed leaking callback data in ThreadSend()
  <p>(tx to Gustaf Neumann)
  <p>(Backported from trunk [d0f7d0adb2])


type: ci
user: jan.nijtmans
comment:
  Use "::tcltest::loadTestedCommands" to make sure that the right Thread version is tested, without requiring explicit version numbers.


type: ci
user: dgp
comment:
  Drop claims of pre-8.6 Tcl support.  Drop AOLserver support claim too until
  someone can vouch for it and restore it.


type: ci
user: jan.nijtmans
comment:
  renamed aolstub.cpp to threadAol.c, and gradually move all NS_AOLSERVER usages to there.
  <p>Duplicate all tsv commands, in case Thread is loaded in AOLserver
  <p>move haveInterpCancel check to ThreadCancel


type: ci
user: jan.nijtmans
comment:
  bug-fix: Allow the thread::wait command to return stack-traces of both the current thread and the waited-for thread.


type: ci
user: jan.nijtmans
comment:
  Use tcl_platform(threaded) on Tcl8.4 and &#91;::tcl::pkgconfig get threaded&#93; on higher Tcl version, for testing whether Tcl is compiled with threads support.


type: t
user: msofer
brief: Ticket [1860425fff]: 4 changes
comment:
  Ticket [1860425fff] <i>core dump on FreeBSD, thread::create</i> status still Open with 4 other changes


type: t
user: elfring
brief: Ticket [659131ffff]: 4 changes
comment:
  Ticket [659131ffff] <i>development targets: Complete pthreads?</i> status still Open with 4 other changes


type: t
user: dgp
brief: Ticket [219320ffff]: 1 change
comment:
  Ticket [219320ffff] <i>Tcl_Finalize doesn't clean-up running threads</i> status still Open with 1 other change


type: t
user: vasiljevic
brief: Ticket [1712723fff]: 4 changes
comment:
  Ticket [1712723fff] <i>joinable threads die on Solaris 64-bit</i> status still Open with 4 other changes


type: t
user: dgp
brief: Ticket [3056785fff]: 4 changes
comment:
  Ticket [3056785fff] <i>update to TEA 3.9 and Thread 2.6.7 release</i> status still Open with 4 other changes


type: t
user: rudenstam
brief: Ticket [1965721fff]: 4 changes
comment:
  Ticket [1965721fff] <i>memory corruption in thread pool ?</i> status still Open with 4 other changes


type: t
user: nobody
brief: Ticket [672050ffff]: 4 changes
comment:
  Ticket [672050ffff] <i>function interface design and namespaces</i> status still Open with 4 other changes


type: t
user: vasiljevic
brief: Ticket [577014ffff]: 4 changes
comment:
  Ticket [577014ffff] <i>documentation; wait on thread exits</i> status still Open with 4 other changes


type: t
user: ferrieux
brief: Ticket [2005794fff]: 4 changes
comment:
  Ticket [2005794fff] <i>tpool::create freezes when using minworkers</i> status still Open with 4 other changes


type: t
user: tsanders
brief: Ticket [994229ffff]: 4 changes
comment:
  Ticket [994229ffff] <i>tsv::lock doesn't lock between threads</i> status still Open with 4 other changes


type: t
user: wobster
brief: Ticket [884549ffff]: 1 change
comment:
  Ticket [884549ffff] <i>Segmentation fault returning value in Thread for Thread 2.5</i> status still Open with 1 other change


type: t
user: arius-marius
brief: Ticket [3532972fff]: 4 changes
comment:
  Ticket [3532972fff] <i>Tcl Scripts results in &quot;called Tcl_FindHashEntry on deleted&quot;</i> status still Open with 4 other changes


type: t
user: sebres
brief: Ticket [3493120fff]: 1 change
comment:
  Ticket [3493120fff] <i>Thread extension, memory leak after thread exit</i> status still Open with 1 other change


type: t
user: decosterjos
brief: Ticket [3543020fff]: 4 changes
comment:
  Ticket [3543020fff] <i>Thread extension not building with makefile. when in release</i> status still Open with 4 other changes


type: t
user: vasiljevic
brief: Ticket [1988779fff]: 4 changes
comment:
  Ticket [1988779fff] <i>Tcl_SetStringObj called with shared object</i> status still Open with 4 other changes


type: t
user: vasiljevic
brief: Closed ticket [219320ffff].
comment:
  Closed ticket [219320ffff]: <i>Tcl_Finalize doesn't clean-up running threads</i> plus 4 other changes


type: t
user: vasiljevic
brief: Pending ticket [3026061fff].
comment:
  Pending ticket [3026061fff]: <i>threadCmd.c:Init() references an interp but not preserves it</i> plus 7 other changes


type: t
user: ctasada
brief: Ticket [1523697fff]: 4 changes
comment:
  Ticket [1523697fff] <i>Crash using clock commands in a Thread using VFS</i> status still Open with 4 other changes


type: t
user: davygrvy
brief: Ticket [418693ffff]: 1 change
comment:
  Ticket [418693ffff] <i>thread extension not resposible for this</i> status still Open with 1 other change


type: t
user: vasiljevic
brief: Closed ticket [2050025fff].
comment:
  Closed ticket [2050025fff]: <i>Threads extension fails to install in custom location</i> plus 7 other changes


type: t
user: vasiljevic
brief: Ticket [762398ffff]: 4 changes
comment:
  Ticket [762398ffff] <i>support thread priority (Windows only)</i> status still Open with 4 other changes


type: t
user: nickpa
brief: New ticket [1358496fff].
comment:
  New ticket [1358496fff] <i>ttrace::eval &quot;wrong # args: should be &quot;proc name args body&quot;&quot;</i>.


type: t
user: vasiljevic
brief: Ticket [745976ffff]: 4 changes
comment:
  Ticket [745976ffff] <i>Thread Extension missing 2.5.2 CVS tag</i> status still Open with 4 other changes


type: t
user: ferrieux
brief: Ticket [3129844fff]: 4 changes
comment:
  Ticket [3129844fff] <i>Thread hangs on specific exit sequence</i> status still Open with 4 other changes


type: t
user: msofer
brief: Ticket [486399ffff]: 1 change
comment:
  Ticket [486399ffff] <i>Panic on exit before all threads returned</i> status still Open with 1 other change


type: t
user: hobbs
brief: Ticket [1934666fff]: 4 changes
comment:
  Ticket [1934666fff] <i>Core dump when using 'clock format ...' in a thread</i> status still Open with 4 other changes


type: t
user: dgp
brief: Ticket [1521416fff]: 1 change
comment:
  Ticket [1521416fff] <i>thread::release on win32 does not release all memory</i> status still Open with 1 other change


type: t
user: hobbs
brief: Closed ticket [1523697fff].
comment:
  Closed ticket [1523697fff]: <i>Crash using clock commands in a Thread using VFS</i> plus 7 other changes


type: t
user: dgp
brief: Closed ticket [3091176fff].
comment:
  Closed ticket [3091176fff]: <i>Ttrace package out of sync with Thread package</i> plus 7 other changes


type: t
user: vasiljevic
brief: Closed ticket [746352ffff].
comment:
  Closed ticket [746352ffff]: <i>warnings: operator== and not all paths return a value</i> plus 6 other changes


type: t
user: dgp
brief: Ticket [3532972fff]: 1 change
comment:
  Ticket [3532972fff] <i>Tcl Scripts results in &quot;called Tcl_FindHashEntry on deleted&quot;</i> status still Open with 1 other change


type: t
user: mistachkin
brief: Ticket [3411244fff]: 5 changes
comment:
  Ticket [3411244fff] <i>[thread::release -wait [thread::id]] hangs</i> status still Open with 5 other changes


type: t
user: vasiljevic
brief: Closed ticket [2980235fff].
comment:
  Closed ticket [2980235fff]: <i>command pollution in interps w/o package require</i> plus 7 other changes


type: t
user: davygrvy
comment:
  Add attachment [/artifact/8c247426c5fee779|patch_thread_ext_stop_grinding_other_peoples_events.txt] to ticket [418693ffffffffff]


type: t
user: sebres
brief: Ticket [3493120fff]: 4 changes
comment:
  Ticket [3493120fff] <i>Thread extension, memory leak after thread exit</i> status still Open with 4 other changes


type: t
user: elfring
brief: Ticket [674367ffff]: 4 changes
comment:
  Ticket [674367ffff] <i>call for a function that is not thread safe</i> status still Open with 4 other changes


type: t
user: twylite
brief: Ticket [1835061fff]: 4 changes
comment:
  Ticket [1835061fff] <i>Fail to build and test thread on Win32/MSVC</i> status still Open with 4 other changes


type: t
user: andreas_kupries
brief: Ticket [1021078fff]: 1 change
comment:
  Ticket [1021078fff] <i>thread::transfer cause exception (TIP #218)</i> status still Open with 1 other change


type: t
user: dgp
brief: Ticket [487213ffff]: 4 changes
comment:
  Ticket [487213ffff] <i>Thread does not build with Tcl 8.3</i> status still Open with 4 other changes


type: t
user: elfring
brief: Ticket [674514ffff]: 6 changes
comment:
  Ticket [674514ffff] <i>Is Tcllib thread safe? - code analysis, flaw detection</i> status still Closed with 6 other changes


type: t
user: sf-robot
brief: Closed ticket [3026061fff].
comment:
  Closed ticket [3026061fff]: <i>threadCmd.c:Init() references an interp but not preserves it</i> plus 6 other changes


type: t
user: nickpa
brief: Ticket [1356721fff]: 4 changes
comment:
  Ticket [1356721fff] <i>tcl8.5a3 segfault foreach loop thread creation</i> status still Open with 4 other changes


type: t
user: tomkiti
brief: Ticket [3534440fff]: 4 changes
comment:
  Ticket [3534440fff] <i>tpool::wait does not return pending jobs</i> status still Open with 4 other changes


type: t
user: dgp
brief: Ticket [503446ffff]: 4 changes
comment:
  Ticket [503446ffff] <i>Thread: Installation of headers fails</i> status still Open with 4 other changes


type: t
user: mdejong
brief: Ticket [584123ffff]: 6 changes
comment:
  Ticket [584123ffff] <i>Patch to fully stub enable Thread packag</i> status still Closed with 6 other changes


type: t
user: dgp
brief: Ticket [1163357fff]: 4 changes
comment:
  Ticket [1163357fff] <i>build dir outside source dir not supported</i> status still Open with 4 other changes


type: t
user: davygrvy
brief: Ticket [219324ffff]: 5 changes
comment:
  Ticket [219324ffff] <i>(tcltest) ThreadErrorProc not always called</i> status still Open with 5 other changes


type: t
user: vasiljevic
brief: Ticket [659131ffff]: 6 changes
comment:
  Ticket [659131ffff] <i>development targets: Complete pthreads?</i> status still Pending with 6 other changes


type: t
user: davygrvy
brief: Ticket [219320ffff]: 4 changes
comment:
  Ticket [219320ffff] <i>Tcl_Finalize doesn't clean-up running threads</i> status still Open with 4 other changes


type: t
user: davygrvy
brief: Ticket [421246ffff]: 1 change
comment:
  Ticket [421246ffff] <i>Problem with unix compilation in thread/</i> status still Open with 1 other change


type: t
user: auriocus
comment:
  Add attachment [/artifact/b460f9be6314afc4|threadpool_leakdemo84_slow.tcl] to ticket [3382401fffffffff]


type: t
user: vasiljevic
brief: Closed ticket [3534442fff].
comment:
  Closed ticket [3534442fff]: <i>tpool::create -idletime documentation incorrect</i> plus 6 other changes


type: t
user: vasiljevic
brief: Ticket [1267256fff]: 4 changes
comment:
  Ticket [1267256fff] <i>enable static linking when TclX is present</i> status still Open with 4 other changes


type: t
user: matt-newman
brief: Ticket [1267256fff]: 5 changes
comment:
  Ticket [1267256fff] <i>enable static linking when TclX is present</i> status still Closed with 5 other changes


type: t
user: vasiljevic
brief: Ticket [2050025fff]: 4 changes
comment:
  Ticket [2050025fff] <i>Threads extension fails to install in custom location</i> status still Open with 4 other changes


type: t
user: mistachkin
brief: Ticket [3411244fff]: 4 changes
comment:
  Ticket [3411244fff] <i>[thread::release -wait [thread::id]] hangs</i> status still Open with 4 other changes


type: t
user: hobbs
brief: Ticket [1934666fff]: 5 changes
comment:
  Ticket [1934666fff] <i>Core dump when using 'clock format ...' in a thread</i> status still Open with 5 other changes


type: t
user: furukawa
brief: Ticket [1245204fff]: 4 changes
comment:
  Ticket [1245204fff] <i>Support for non-standard gdbm location</i> status still Open with 4 other changes


type: t
user: dgp
brief: Ticket [3057497fff]: 4 changes
comment:
  Ticket [3057497fff] <i>pkgIndex versions out of date on Win32</i> status still Open with 4 other changes


type: t
user: mdejong
brief: Ticket [584123ffff]: 4 changes
comment:
  Ticket [584123ffff] <i>Patch to fully stub enable Thread packag</i> status still Open with 4 other changes


type: t
user: mistachkin
brief: Ticket [1521416fff]: 4 changes
comment:
  Ticket [1521416fff] <i>thread::release on win32 does not release all memory</i> status still Open with 4 other changes


type: t
user: andreas_kupries
brief: Ticket [2980235fff]: 4 changes
comment:
  Ticket [2980235fff] <i>command pollution in interps w/o package require</i> status still Open with 4 other changes


type: t
user: sebres
brief: Ticket [1521416fff]: 4 changes
comment:
  Ticket [1521416fff] <i>thread::release on win32 does not release all memory</i> status still Pending with 4 other changes


type: t
user: vasiljevic
brief: Ticket [3534442fff]: 5 changes
comment:
  Ticket [3534442fff] <i>tpool::create -idletime documentation incorrect</i> status still Open with 5 other changes


type: t
user: dkf
brief: Ticket [1021078fff]: 5 changes
comment:
  Ticket [1021078fff] <i>thread::transfer cause exception (TIP #218)</i> status still Open with 5 other changes


type: t
user: davygrvy
brief: Ticket [219324ffff]: 2 changes
comment:
  Ticket [219324ffff] <i>(tcltest) ThreadErrorProc not always called</i> status still Open with 2 other changes


type: t
user: vasiljevic
brief: Ticket [3534607fff]: 5 changes
comment:
  Ticket [3534607fff] <i>tpool::get sets errorInfo incorrectly</i> status still Open with 5 other changes


type: t
user: twylite
brief: Ticket [1689375fff]: 4 changes
comment:
  Ticket [1689375fff] <i>Update VC makefile for Threads (Fix for bug 1643367)</i> status still Open with 4 other changes


type: t
user: dgp
brief: Open ticket [1521416fff].
comment:
  Open ticket [1521416fff]: <i>thread::release on win32 does not release all memory</i> plus 6 other changes


type: t
user: ferrieux
brief: Ticket [486399ffff]: 4 changes
comment:
  Ticket [486399ffff] <i>Panic on exit before all threads returned</i> status still Open with 4 other changes


type: t
user: dgp
brief: Ticket [3056785fff]: 5 changes
comment:
  Ticket [3056785fff] <i>update to TEA 3.9 and Thread 2.6.7 release</i> status still Open with 5 other changes


type: t
user: davygrvy
brief: Ticket [219324ffff]: 4 changes
comment:
  Ticket [219324ffff] <i>(tcltest) ThreadErrorProc not always called</i> status still Open with 4 other changes


type: t
user: elfring
brief: Ticket [674514ffff]: 5 changes
comment:
  Ticket [674514ffff] <i>Is Tcllib thread safe? - code analysis, flaw detection</i> status still Open with 5 other changes


type: t
user: dgp
brief: Ticket [1505810fff]: 4 changes
comment:
  Ticket [1505810fff] <i>init.tcl not found in thread interpreter </i> status still Open with 4 other changes


type: t
user: dgp
brief: Ticket [3543020fff]: 1 change
comment:
  Ticket [3543020fff] <i>Thread extension not building with makefile. when in release</i> status still Open with 1 other change


type: t
user: wobster
brief: Ticket [884549ffff]: 4 changes
comment:
  Ticket [884549ffff] <i>Segmentation fault returning value in Thread for Thread 2.5</i> status still Open with 4 other changes


type: t
user: dkf
brief: Ticket [1073161fff]: 1 change
comment:
  Ticket [1073161fff] <i>Wrong assignment in ListRemoveInner</i> status still Open with 1 other change


type: t
user: elfring
brief: Ticket [659131ffff]: 4 changes
comment:
  Ticket [659131ffff] <i>development targets: Complete pthreads?</i> status still Closed with 4 other changes


type: t
user: vasiljevic
brief: Ticket [674514ffff]: 4 changes
comment:
  Ticket [674514ffff] <i>Is Tcllib thread safe? - code analysis, flaw detection</i> status still Open with 4 other changes


type: t
user: vasiljevic
brief: Ticket [3129844fff]: 4 changes
comment:
  Ticket [3129844fff] <i>Thread hangs on specific exit sequence</i> status still Closed with 4 other changes


type: t
user: tombert
brief: Ticket [3129844fff]: 1 change
comment:
  Ticket [3129844fff] <i>Thread hangs on specific exit sequence</i> status still Open with 1 other change


type: t
user: dgp
brief: Ticket [3383288fff]: 6 changes
comment:
  Ticket [3383288fff] <i>rules.vc missing support for MSVC10</i> status still Open with 6 other changes


type: t
user: twylite
brief: Closed ticket [1716587fff].
comment:
  Closed ticket [1716587fff]: <i>Thread tests can't run (bad args from makefile)</i> plus 7 other changes


type: t
user: decosterjos
brief: Open ticket [3543020fff].
comment:
  Open ticket [3543020fff]: <i>Thread extension not building with makefile. when in release</i> plus 4 other changes


type: t
user: dkf
brief: Closed ticket [674514ffff].
comment:
  Closed ticket [674514ffff]: <i>Is Tcllib thread safe? - code analysis, flaw detection</i> plus 7 other changes


type: t
user: twylite
brief: Ticket [1716587fff]: 4 changes
comment:
  Ticket [1716587fff] <i>Thread tests can't run (bad args from makefile)</i> status still Open with 4 other changes


type: t
user: vasiljevic
brief: Closed ticket [884549ffff].
comment:
  Closed ticket [884549ffff]: <i>Segmentation fault returning value in Thread for Thread 2.5</i> plus 6 other changes


type: t
user: mistachkin
brief: Ticket [3439599fff]: 4 changes
comment:
  Ticket [3439599fff] <i>thread::cancel not reporting error</i> status still Open with 4 other changes


type: t
user: twylite
comment:
  Add attachment [/artifact/77532e44c4c7aa56|tcl-thread-build-20071120.patch] to ticket [1835061fffffffff]


type: t
user: hobbs
brief: Closed ticket [1462274fff].
comment:
  Closed ticket [1462274fff]: <i>Out-of-date version number in Win32 VC makefiles</i> plus 7 other changes


type: t
user: ferrieux
brief: Ticket [2005794fff]: 4 changes
comment:
  Ticket [2005794fff] <i>tpool::create freezes when using minworkers</i> status still Closed with 4 other changes


type: t
user: vasiljevic
brief: Closed ticket [3027815fff].
comment:
  Closed ticket [3027815fff]: <i>Safe interpreters can use Thread to execute unsafe commands</i> plus 7 other changes


type: t
user: oehhar
brief: Ticket [3567104fff]: 4 changes
comment:
  Ticket [3567104fff] <i>pkgIndex.tcl bronken when building with Makefile.vc</i> status still Open with 4 other changes


type: t
user: rtreleaven
brief: Ticket [3494470fff]: 4 changes
comment:
  Ticket [3494470fff] <i>called Tcl_FindHashEntry on deleted table</i> status still Open with 4 other changes


type: t
user: dkf
brief: Ticket [1860425fff]: 3 changes
comment:
  Ticket [1860425fff] <i>core dump on FreeBSD, thread::create</i> status still Open with 3 other changes


type: t
user: mistachkin
brief: Closed ticket [1521416fff].
comment:
  Closed ticket [1521416fff]: <i>thread::release on win32 does not release all memory</i> plus 8 other changes


type: t
user: vasiljevic
brief: Ticket [1512225fff]: 4 changes
comment:
  Ticket [1512225fff] <i>tpool::wait and tpool::cancel set wrong value to variable</i> status still Open with 4 other changes


type: t
user: decosterjos
brief: Ticket [3543020fff]: 4 changes
comment:
  Ticket [3543020fff] <i>Thread extension not building with makefile. when in release</i> status still Pending with 4 other changes


type: t
user: ferrieux
brief: Ticket [2511424fff]: 4 changes
comment:
  Ticket [2511424fff] <i>condition variable error in thread-21.16</i> status still Open with 4 other changes


type: t
user: hobbs
brief: Ticket [2050025fff]: 4 changes
comment:
  Ticket [2050025fff] <i>Threads extension fails to install in custom location</i> status still Closed with 4 other changes


type: t
user: ferrieux
brief: Ticket [2511424fff]: 5 changes
comment:
  Ticket [2511424fff] <i>condition variable error in thread-21.16</i> status still Open with 5 other changes


type: t
user: vasiljevic
brief: Closed ticket [1512225fff].
comment:
  Closed ticket [1512225fff]: <i>tpool::wait and tpool::cancel set wrong value to variable</i> plus 3 other changes


type: t
user: vasiljevic
brief: Ticket [3026061fff]: 4 changes
comment:
  Ticket [3026061fff] <i>threadCmd.c:Init() references an interp but not preserves it</i> status still Open with 4 other changes


type: t
user: andreas_kupries
brief: Ticket [503446ffff]: 1 change
comment:
  Ticket [503446ffff] <i>Thread: Installation of headers fails</i> status still Open with 1 other change


type: t
user: dgp
brief: Ticket [1745928fff]: 4 changes
comment:
  Ticket [1745928fff] <i>thread's memory isn't being released</i> status still Open with 4 other changes


type: t
user: elfring
brief: Ticket [674514ffff]: 7 changes
comment:
  Ticket [674514ffff] <i>Is Tcllib thread safe? - code analysis, flaw detection</i> status still Closed with 7 other changes


type: t
user: dkf
brief: Ticket [3027815fff]: 4 changes
comment:
  Ticket [3027815fff] <i>Safe interpreters can use Thread to execute unsafe commands</i> status still Open with 4 other changes


type: t
user: andreas_kupries
brief: Closed ticket [503451ffff].
comment:
  Closed ticket [503451ffff]: <i>Thread: Unknown &quot;ThreadKill&quot; function</i> plus 8 other changes


type: t
user: sebres
brief: Ticket [3494470fff]: 6 changes
comment:
  Ticket [3494470fff] <i>called Tcl_FindHashEntry on deleted table</i> status still Open with 6 other changes


type: t
user: andreas_kupries
brief: Ticket [439581ffff]: 3 changes
comment:
  Ticket [439581ffff] <i>crash when application terminates</i> status still Closed with 3 other changes


type: t
user: dkf
brief: Ticket [2688159fff]: 4 changes
comment:
  Ticket [2688159fff] <i>Thread module fails to build against 8.6b1</i> status still Open with 4 other changes


type: t
user: dgp
brief: Ticket [1860425fff]: 1 change
comment:
  Ticket [1860425fff] <i>core dump on FreeBSD, thread::create</i> status still Open with 1 other change


type: t
user: davygrvy
comment:
  Add attachment [/artifact/bdfb66aac726cab5|patch_thread_ext_add_finalize.txt] to ticket [418689ffffffffff]


type: t
user: hobbs
brief: Ticket [1267256fff]: 1 change
comment:
  Ticket [1267256fff] <i>enable static linking when TclX is present</i> status still Open with 1 other change


type: t
user: dgp
brief: Ticket [3447273fff]: 4 changes
comment:
  Ticket [3447273fff] <i>tpool::* commands respect interp limits</i> status still Open with 4 other changes


type: t
user: twylite
brief: Ticket [1643367fff]: 4 changes
comment:
  Ticket [1643367fff] <i>Thread extension cannot compile with VC8</i> status still Open with 4 other changes


type: t
user: vasiljevic
brief: Ticket [1578877fff]: 4 changes
comment:
  Ticket [1578877fff] <i>thread::release treats hanging processes wrongly</i> status still Open with 4 other changes


type: t
user: vasiljevic
brief: Ticket [219320ffff]: 2 changes
comment:
  Ticket [219320ffff] <i>Tcl_Finalize doesn't clean-up running threads</i> status still Closed with 2 other changes


type: t
user: dkf
brief: Closed ticket [3033206fff].
comment:
  Closed ticket [3033206fff]: <i>lib/ttrace.tcl uses ::version as temporary variable</i> plus 8 other changes


type: t
user: nijtmans
brief: Pending ticket [3543020fff].
comment:
  Pending ticket [3543020fff]: <i>Thread extension not building with makefile. when in release</i> plus 6 other changes


type: t
user: dgp
brief: Pending ticket [1521416fff].
comment:
  Pending ticket [1521416fff]: <i>thread::release on win32 does not release all memory</i> plus 8 other changes


type: t
user: vasiljevic
brief: Ticket [1095370fff]: 2 changes
comment:
  Ticket [1095370fff] <i>tpool doesn't respect -minworkers</i> status still Closed with 2 other changes


type: t
user: nijtmans
brief: Closed ticket [3543020fff].
comment:
  Closed ticket [3543020fff]: <i>Thread extension not building with makefile. when in release</i> plus 6 other changes


type: t
user: vasiljevic
brief: Ticket [1521416fff]: 5 changes
comment:
  Ticket [1521416fff] <i>thread::release on win32 does not release all memory</i> status still Open with 5 other changes


type: t
user: lvirden
brief: Ticket [1712723fff]: 5 changes
comment:
  Ticket [1712723fff] <i>thread.test bus error on sparc solaris 9</i> status still Open with 5 other changes


type: t
user: nijtmans
brief: Pending ticket [3543020fff].
comment:
  Pending ticket [3543020fff]: <i>Thread extension not building with makefile. when in release</i> plus 8 other changes


type: t
user: oehhar
brief: Closed ticket [3567104fff].
comment:
  Closed ticket [3567104fff]: <i>pkgIndex.tcl bronken when building with Makefile.vc</i> plus 3 other changes


type: t
user: tomkiti
brief: Ticket [3534607fff]: 4 changes
comment:
  Ticket [3534607fff] <i>tpool::get sets errorInfo incorrectly</i> status still Open with 4 other changes


type: t
user: hobbs
brief: Ticket [1712723fff]: 6 changes
comment:
  Ticket [1712723fff] <i>joinable threads die on Solaris 64-bit</i> status still Open with 6 other changes


type: t
user: vasiljevic
brief: Closed ticket [1358496fff].
comment:
  Closed ticket [1358496fff]: <i>ttrace::eval &quot;wrong # args: should be &quot;proc name args body&quot;&quot;</i> plus 7 other changes


type: t
user: ctasada
brief: Ticket [1523697fff]: 2 changes
comment:
  Ticket [1523697fff] <i>Crash using clock commands in a Thread using VFS</i> status still Open with 2 other changes


type: t
user: auriocus
comment:
  Add attachment [/artifact/16f3c1b515df64a2|threadpool_leakdemo84_fast.tcl] to ticket [3382401fffffffff]


type: t
user: arius-marius
brief: New ticket [3532972fff].
comment:
  New ticket [3532972fff] <i>Tcl Scripts results in &quot;called Tcl_FindHashEntry on deleted&quot;</i>.


type: t
user: ferrieux
brief: Ticket [486399ffff]: 5 changes
comment:
  Ticket [486399ffff] <i>Panic on exit before all threads returned</i> status still Open with 5 other changes


type: t
user: davygrvy
brief: Ticket [418693ffff]: 4 changes
comment:
  Ticket [418693ffff] <i>thread extension not resposible for this</i> status still Open with 4 other changes


type: t
user: dkf
brief: Ticket [486399ffff]: 4 changes
comment:
  Ticket [486399ffff] <i>Panic on exit before all threads returned</i> status still Closed with 4 other changes


type: t
user: hobbs
brief: Closed ticket [1934666fff].
comment:
  Closed ticket [1934666fff]: <i>Core dump when using 'clock format ...' in a thread</i> plus 3 other changes


type: t
user: vasiljevic
brief: Ticket [1095370fff]: 4 changes
comment:
  Ticket [1095370fff] <i>tpool doesn't respect -minworkers</i> status still Closed with 4 other changes


type: t
user: vasiljevic
brief: Closed ticket [1356721fff].
comment:
  Closed ticket [1356721fff]: <i>tcl8.5a3 segfault foreach loop thread creation</i> plus 7 other changes


type: t
user: elfring
brief: Ticket [659131ffff]: 5 changes
comment:
  Ticket [659131ffff] <i>development targets: Complete pthreads?</i> status still Open with 5 other changes


type: t
user: furukawa
comment:
  Add attachment [/artifact/5fcbaa8bf15eb1a2|thread2.6.1-aclocal.m4.patch] to ticket [1245204fffffffff]


type: t
user: vasiljevic
brief: Ticket [3534440fff]: 5 changes
comment:
  Ticket [3534440fff] <i>tpool::wait does not return pending jobs</i> status still Open with 5 other changes


type: t
user: vasiljevic
brief: Closed ticket [1578877fff].
comment:
  Closed ticket [1578877fff]: <i>thread::release treats hanging processes wrongly</i> plus 7 other changes


type: ci
user: jan.nijtmans
comment:
  Allow Thread 2.7 to be loaded in Tcl 9.0 "novem"on 32-bit platforms. On 64-bit platforms that's impossible because binary incompatibilies are planned.


type: ci
user: jan.nijtmans
comment:
  Fix bug reported by Gustaf Neumann:

  just found a bug in thread 2.7.0. When NS_AOLSERVER is defined, thread2.7.0
  defines for every function a second tcl-command called cmdPtr->cmdName2,
  (e.g. sv_set something abc 123), which gets 1 as ClientData passed.
  The command implementations treat the passed clientData as Container *,
  which seg faults, when 1 is passed.


type: ci
user: jan.nijtmans
comment:
  K&R -> ANSI-C (patch from Gustaf Neumann)
  Change SvNamesObjCmd, such that it uses the object container from its "args" argument.


type: ci
user: jan.nijtmans
comment:
  Change a few internal variables from type int to type size_t.
  Simplify determination of whether Tcl is compiled with thread support.
  Update to latest TEA.


type: ci
user: jan.nijtmans
ecomment:
  Change some internal variable from int to size_t, so they can handle larger string lengths.
  Eliminate some Tcl_ConvertToType calls.

comment:
  Change some internal variable from int to size_t, so they can handle larger string lengths.
  Eliminate some Tcl_ConvertToObjType calls.


type: ci
user: jan.nijtmans
comment:
  Eliminate the use of internalRep.otherValuePtr everywhere, use internalRep.twoPtrValue.ptr1 in stead


type: ci
user: jan.nijtmans
comment:
  Fix compiler warning. 
  Eliminate all usage of "Long" API: Either use "Int" or "WideInt", which give the same results in 32-bit and 64-bit platforms.


type: ci
user: jan.nijtmans
comment:
  Add runtime detection of Tcl_AddErrorInfo vs. Tcl_AppendObjToErrorInfo and Tcl_GetErrorLine vs.	interp->errorLine.
  Replace Tcl_GetString to Tcl_GetStringFromObj and Tcl_GetStringResult to Tcl_GetObjResult everywhere. This will make it more likely that Thread will run in Tcl9 unmodified, no matter what API changes are made.


type: ci
user: jan.nijtmans
comment:
  merge trunk
  if sizeof(size_t)!=sizeof(int), Thread 2.7 only loads in the same Tcl major version as it was compiled with.


type: ci
user: jan.nijtmans
comment:
  Make "novem" compilable against Tcl's "novem-64bit-sizes". Highly experimental.
  Still compiles/runs fine when compiled against "novem" branch, crashes when using "novem-64bit-sizes" branch!


type: ci
user: jan.nijtmans
comment:
  Allow Thread to be loaded by 8.4 up to novem, no matter what headers it is compiled with. 
  I don't think it's wise for Thread 2.7 to go this way, but it is meant to investigate what we can do in Tcl_InitStubs() to protect extension authors from obvious mistakes.


type: ci
user: jan.nijtmans
comment:
  Take over some changes from novem-support.
  The "novem" branch should only be compilable on Tcl 9.0+,
  but on 32-bit platforms it should be runnable on Tcl 8.6 as well.
  Reason: Tcl 9.0 should be source compatible with 8.6 with some
  restrictions: Some API's might be removed, others added, and
  many (unsigned) int/long arguments might become size_t or ssize_t.
  Thread doesn't need any of the added API's, only the common
  subset of Tcl 8.6/9.0. On 32-bit platforms, int/long/size_t all have
  the same size, so that should not influence the runnability.


type: ci
user: dgp
comment:
  Minimal changes to let Thread 2.7.0, etc. build against novem headers, and
  [load] into novem interps.


type: ci
user: jan.nijtmans
comment:
  merge-mark rc branch to trunk (indicating that the 2.7b1 -> 2.7.0 renaming is already done on trunk now)


type: ci
user: jan.nijtmans
comment:
  Fix minor compiler warning.
  Some direct calls of functions which are thin wrappers around other functions.


type: ci
user: mistachkin
comment:
  Restore compile-time and runtime checks for TIP #143 and #285; by default, enable at compile-time and check availability at runtime.


type: ci
user: jan.nijtmans
comment:
  Eliminate deprecation warning regarding interp->errorLine. Can only be done when Tcl 8.6 provides Tcl_GetErrorLine as macro


type: ci
user: jan.nijtmans
ecomment:
  Missing changelog entry for Joe's work.
  <p>Move back test for core threaded functionality from pkgIndex.tcl to threadCmd.c, so it cannot be circumvented any more.

comment:
  Missing changelog entry for Joe's work.
  <p>Move back test for core threaded functionality from pkgIndex.tcl to threadCmd.c, so it cannot be escaped any more.


type: t
user: anonymous
brief: New ticket [4e30d60da7].
comment:
  New ticket [4e30d60da7] <i>Error message is doubled in -errorinfo in rethrown exception using tpool::get</i>.


type: ci
user: andreask
comment:
  Added conditional definition of MODULE_SCOPE for cases where it does
  not exist (Building basekits, tclkits, with Thread directly compiled
  in). This required modification of some header inclusions as well, to
  have the definition in one place instead of about four.

  Added conditional definition of Tcl_GetErrorLine for the same
  reason. Under static build -DTCL_TIP285 is not usable, as
  USE_TCL_STUBS will be missing. And the TGEL changes are TIP 336 also,
  i.e. unrelated.

  And lastly added conditional definition of the package version, again
  for cases where it is missing due to Thread configure not invoked.


type: t
user: anonymous
brief: Ticket [4e30d60da7]: 4 changes
comment:
  Ticket [4e30d60da7] <i>Error message is doubled in -errorinfo in rethrown exception using tpool::get</i> status still Open with 4 other changes


type: ci
user: jan.nijtmans
comment:
  Ticket [http://core.tcl.tk/tclconfig/tktview?name=00ed054f4f|00ed054f4f]: Search in Debian per-version directories


type: t
user: jan.nijtmans
brief: Closed ticket [4e30d60da7].
comment:
  Closed ticket [4e30d60da7]: <i>Error message is doubled in -errorinfo in rethrown exception using tpool::get</i> plus 7 other changes


# ticket

tkt_uuid: d2df28c065755b0ad144b9519550bb7f4a0a73aa
type: Code_Defect
status: Open
severity: Critical
foundin: 2afed999e3
private_contact: 2f102b33d8f807336292e56ff47c6c59de4876c0
title: repo missing two files
comment:
  It appears the repo is missing two files that were present in older (2.6.5, 2008(?)) Sourceforge repos. This will cause ./configure to bail.

  files in question:

  * tclconfig/tcl.m4

  * tclconfig/install-sh

  I copied these files into place on my own system, and ./configure and build did run to completion.


tkt_uuid: 1021053fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 9 Immediate
foundin: obsolete: 8.4.7
resolution: Duplicate
title: thread::transfer cause exception
comment:
  running this script on windows xp Home
  tcl 8.4.7 threaded 
  thread version 2.6

  when trying to read from a socket after it was 
  transfered to the thread using "thread::transfer" I get 
  exception. the same happens with "thread::attach" 
  and "thread::detach"

  here is the script:

  package require Thread

  proc acceptRequest {sock ip port} {
  after idle [list handleRequest $sock $ip $port 
  [thread::id]]
  }

  proc handleRequest {sock ip port mainThreadId} {
  puts "$sock $ip $port"
  global threadId
  #thread::detach $sock
  thread::transfer $threadId $sock
  thread::send $threadId [list doSock $sock]
  }
  set threadId [thread::create]
  thread::send $threadId {
  proc doSock {sock}  {
  #thread::attach $sock
  puts [gets $sock 1]
  close $sock
  }
  }
  set sock [socket -server acceptRequest 7790]
  vwait foreve


tkt_uuid: 1050490fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Fixed
title: invalid ref in ThreadSetResult
comment:
  ThreadSetResult gets a pointer
  to the string rep of an interp result:

      result = Tcl_GetStringResult(interp);

  then keeps on using that pointer after
  the interp's doing other things, making
  no effort to preserve the result.

  Recent changes on the Tcl HEAD allow
  that result to change out from under us.

  Here's a simple patch to correct.
  Without it, you will see tests fail.


tkt_uuid: 1051068fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 80. Thread Package
priority: 9 Immediate
foundin: None
resolution: Fixed
title: Testsuite crashes, Windows, 8.4
comment:
  Running testsuite of thread against an 8.5 core (head)
  is ok. doing the same against an 8.4 core (branch head)
  crashes the tests 14.4, 19.8, 19.9, and 19.11. This is
  always in Sp_RecursiveMutexUnlock (threadSpCmd.c, line
  1395). It actually gpf's in the NTDLL function called
  from that location.

  The platform is Win 2000. The thread package was CVS
  head as well.


tkt_uuid: 1073161fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 9 Immediate
foundin: None
resolution: Wont Fix
title: Wrong assignment in ListRemoveInner
comment:
  leopold.gerlinger@siemens.com

  During compilation of Thread 2.5.2 i saw a compiler 
  warning in procedure 'ListRemoveInner'. Test for equality 
  where an assignment is expected - I believe.

  Code follows:

  static void
  ListRemoveInner(tsdPtr)
      ThreadSpecificData *tsdPtr;
  {
      if (tsdPtr->prevPtr || tsdPtr->nextPtr) {
          if (tsdPtr->prevPtr) {
              tsdPtr->prevPtr->nextPtr = tsdPtr->nextPtr;
          } else {
              threadList = tsdPtr->nextPtr;
          }
          if (tsdPtr->nextPtr) {
              tsdPtr->nextPtr->prevPtr = tsdPtr->prevPtr;
          }
          tsdPtr->nextPtr = NULL;
          tsdPtr->prevPtr = NULL;
      } else if (tsdPtr == threadList) {
          threadList == NULL;
      }
  }

  The last statement should read (IMHO):

          threadList = NULL;


tkt_uuid: 1076117fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Fixed
title: cvs head thread package configure bugs
comment:
  1. Thread package assumes that gdbm will be installed
  in one of only 4 places - $exec_prefix $prefix,
  /usr/local, or /usr .
  However, users have this package installed elsewhere as
  well.

  2. The code in configure has a bug when checking for
  existence of the library.  It is coded:

  for i in `ls -d ${exec_prefix}/lib 2>/dev/null` \
                  `ls -d ${prefix}/lib 2>/dev/null` \
                  `ls -d /usr/local/lib 2>/dev/null` \
                  `ls -d /usr/lib 2>/dev/null` ; do
              if test -f "$i/libgdbm*" ; then
                  libdir=`(cd $i; pwd)`
                  break
              fi
          done


  This, however, makes the assumption that there will
  never be more than one file in the directory which
  begins libgdbm.  If the user has more than one version
  installed, or the installation looks like:
  /projects/gnu/sparc-sun-solaris2.8/lib/libgdbm.so.3.0.0
  /projects/gnu/sparc-sun-solaris2.8/lib/libgdbm.so.3
  /projects/gnu/sparc-sun-solaris2.8/lib/libgdbm.so
  /projects/gnu/sparc-sun-solaris2.8/lib/libgdbm.la
  /projects/gnu/sparc-sun-solaris2.8/lib/libgdbm.a

  then the if fails to identify that the library exists
  in this directory (because there's a list used in a
  place where a single file name is  expected....)


tkt_uuid: 1095370fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Fixed
title: tpool doesn't respect -minworkers
comment:
  -minworkers threads are started, but but if they
  are unused for -idletime, they are killed off.
  This is contrary to the documentation and
  to the "appropriate" behavior for this paradigm.


tkt_uuid: 1095535fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Fixed
title: Wrong Documentation
comment:
  The documentation for Thread 2.5.2 contains the following:

  tsv::exists
      Checks wether the element exists in the shared
  array. If the element is not given it tests the
  existence of the array itself. Returns true (1) if the
  item exists, false (0) if not.


  However, given a shared array 'MyArray' and executing
  the command
  tsv::exists MyArray 
  the following error is raised:
  wrong # args: should be "tsv::exists array key ?args?"
      while executing
  "tsv::exists MyArray"

  The command
  tsv::array exists MyArray
  must be used in this case.


tkt_uuid: 1163357fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.5a3
resolution: Fixed
title: build dir outside source dir not supported
comment:
  $ gunzip -c thread2.6.1.tar.gz | tar xf -
  $ mkdir build
  $ cd build
  $ ../thread2.6.1/configure
  ...
  $ make test
  ...
  couldn't read file "./ttrace.tcl": no such file or
  directory
      while executing
  "source [file join . ttrace.tcl]"
      invoked from within
  "if {[file readable [file join . .. lib ttrace.tcl]]} { 
              source [file join . .. lib ttrace.tcl]
          } else {
              source [file j..."
      ("package ifneeded" script)
      invoked from within
  "package require Thread 2.6"
      (file "../thread2.6.1/tests/all.tcl" line 46)

  The pkgIndex.tcl file is constructed to
  look for the files ../lib/ttrace.tcl or ttrace.tcl
  relative to the $dir that holds pkgIndex.tcl.
  This implies that only builds in subdirs of
  thread.2.6.1 can be tested prior to installation.

  It should not be so.  Other build dirs should
  be supported.


tkt_uuid: 1245204fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Accepted
title: Support for non-standard gdbm location
comment:
  I'm interested in the persistent variable feature. 
  However, my gdbm is in a non-standard directory. 

  On the configure command line, if we specify
  "--with-gdbm=/directory", a message "error: none found"
  is printed and libgdbm.a is never found.  The library
  file checking structure is not quite right, and the
  simplest fix is to remove the last else clause in
  aclocal.m4.  

  The patch file "thread2.6.1-aclocal.m4.patch" fixes the
  problem, although I think there may be a better fix. I
  think this problem may have been caused by an incorrect
  indentation at the beginning of the file.  

  Cheers.

  Kazuro Furukawa
  kazuro.furukawa at kek.jp


tkt_uuid: 1267256fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 80. Thread Package
priority: 7 High
foundin: None
resolution: Remind
title: enable static linking when TclX is present
comment:
  When you statically link the thread extension w/ the 
  TclX extension you get multiple defines - this patch 
  addresses this issue in a minimal impact way.


tkt_uuid: 1356721fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.5a3
resolution: Out of Date
title: tcl8.5a3 segfault foreach loop thread creation
comment:
  tcl crashes when I launch multiple (5) threads and then 
  send scripts to it (async). 

  running on the following system:

  tclver: 8.5a3 (none cvs)
  os: Linux 2.6.13.4 #1 SMP Mon Oct 17 19:19:27 CEST 
  2005 i686 GNU/Linux (debian)

  I have to add that I have only been able to reproduce the 
  error with 'package require tls' within the newly created 
  threads. Also, it looks like it is some kind of racing 
  condition; it barely crashes on a system with high loads, 
  with low loads it does. 

  Below is an example of what I see when I run the script.

  ns2986:/home/nick/ # /usr/tcl85/bin/tclsh8.5 crash.tcl
  Menu
  l
  launching thead:1
  launching thead:2
  launching thead:3
  Segmentation fault

  NOTE: sometimes I have to start and close the script 
  again and then type 'l' to launch the thread creation, for 
  it to segfault. So it does not ALWAYS crash, it does 
  crash a lot though.

  Hope this helps you guys, might be my system, tls 
  package or TCL.

  I'v attached the script for testing purposes.

  Kind Regards,

  Nick Parrin


tkt_uuid: 1358496fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.5a3
resolution: Fixed
title: ttrace::eval "wrong # args: should be "proc name args body""
comment:
  ttrace::eval does not seem to work properly under 
  Thread 2.6.2. I have tried the same under 2.6.0 and 
  2.6.1, no problem there.

  See the output below:

  nick@ns2986:~/ $ /usr/tcl85/bin/tclsh8.5 
  % package require Thread 2.6.2
  2.6.2
  % ttrace::eval { proc lala {lala} {puts lala}}
  wrong # args: should be "proc name args body"
  % puts $errorInfo
  wrong # args: should be "proc name args body"
      while executing
  "proc lala lala puts lala"
      ("uplevel" body line 1)
      invoked from within
  "::uplevel proc lala {lala} {puts lala}"
      (in namespace eval "::" script line 1)
      invoked from within
  "namespace eval $nmsp ::uplevel $cmd $args"
      invoked from within
  "ttrace::eval { proc lala {lala} {puts lala}}"
  % 


tkt_uuid: 1449383fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: Wont Fix
title: Memory leak in Thread
comment:
  Hi,
         I have found a memory leak problem while using 
  the TCL thread package. The Tcl version is 8.4.13 and 
  Thread version is 2.6.2. I have also attached a sample 
  script to support my findings. The sample script 
  creates & releases 5 threads for 14 times . For each 
  time , the memory of the tclsh process increases by 
  700 kb(avg). I have traced the memory through Windows 
  Task Manager. 

  please forgive me if I had done anything wrong.

  OS version : windows 2000

  Thanks in Advance.

  Gangadharan.


tkt_uuid: 1462274fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 7 High
foundin: None
resolution: Fixed
title: Out-of-date version number in Win32 VC makefiles
comment:
  ./win/vc/pkg.vc:PACKAGE_VERSION = "2.6",
  but the actual version is 2.6.3.

  This causes a mismatch between the "package ifneeded" /
  "package provided" statements used to declare and
  provide the package. 8.4 reports this on stderr, in 8.5
  this is a error.


tkt_uuid: 1464731fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: Wont Fix
title: Memory leak in Thread release
comment:
  Hi,
       It seems there is memory leak in Thread release 
  call. I have attched the sample script for 
  Theread "create/release". For each thread release 
  there was around 65KB of memory leak. More over if I 
  provide any package in Thread send call the leak was 
  pretty much high(400KB).So please have look into this 
  issue and suggest me a solution.

  OS : Windows 2000
  Thanks,
  Karthik
  Email:karthikk@hcl.in


tkt_uuid: 1473261fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: Wont Fix
title: Thread
comment:
  The following code occassionally crashes on Linux/x86 
  and 8.4.13 + thread 2.6.3:

  package require Thread; set t [thread::create]; thread
  ::release $t; exit

  The following error occurs:
  Tcl_Release couldn't find reference for 0x80e0450

  Unfortunately GDB stack trace (attached) does not show 
  much information.

  It happens once each about 20 runs on my machine, it 
  may vary though.


tkt_uuid: 1478402fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Wrong binary in Windows
comment:
  I've just downloaded the Thread 2.6.3 package and I've
  found a strange problem.

  When I load the package (package require Thread 2.6.3)
  sais that the package is not available, but founds
  correctly Thread 2.6.

  Looking in the dll version I see that it's 2.6. I've
  downloaded the sources and recompiled them in Windows,
  with exactly the same beahiviour.

  Seems that the VC makefiles are unsync with the TEA
  makefiles.

  It's quite a simple fix.

  Or maybe I should forget about minor versions in the
  Windows platform?

  Cheers.


tkt_uuid: 1505810fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: Wont Fix
title: init.tcl not found in thread interpreter
comment:
  We are using the thread extension in combination with
  an application specific tcl_library path (in other
  words, in this installation *only* the tcl_library
  variable knows where to find a usable "init.tcl"). With
  thread-2.6.3, when we spawn a new thread using
  "thread::create" that new thread does not find the
  "init.tcl" and is thus slightly handicapped; we
  currently have to manually do the following to get a
  functional thread:

  thread::send $tid [list set tcl_library $tcl_library]
  thread::send $tid {
     source [file join $tcl_library init.tcl]
  } 

  This feels like a hack that better ought to be fixed in
  the thread package itself. 

  Inspecting the code one finds that threadCmd.c executes

      interp = Tcl_CreateInterp();
      result = Tcl_Init(interp);

  in NewThread(clientData). It seems that "result" is
  currently not used, so any failure at that stage
  remains unnoticed. I would suggest to always initialize
  the thread's tcl_library with the parent's tcl_library
  before calling Tcl_Init().


tkt_uuid: 1512225fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: Fixed
title: tpool::wait and tpool::cancel set wrong value to variable
comment:
  tpool::wait and tpool::cancel set wrong value to
  optional variable.


  Windows2000
  ActiveTcl8.4.13
  Thread2.6.3 compiled by VC6


  Sample code for tpool::wait
  -------------------------------------------------------
  set tp [tpool::create -maxworkers 1]
  for {set i 1} {$i < 10} {incr i} {
  puts [tpool::post -nowait $tp [subst {
  puts $i:start
  after 5000
  puts $i:end
  }]]
  }
  puts [tpool::wait $tp {4 5 6} waiting]:DONE
  if {[llength $waiting] != 2} {
  error "waiting is $waiting"
  }


  In this code, only one worker thread is worked.
  So posted jobs are eval one by one.
  When the 4 job is finishing, tpool::wait returns from 
  event loop, and returns number 4, 
  and should set a list of waiting jobs (5 and 6) 
  to "waiting" variable.
  But "waiting" variable is empty list.


  Sample code for tpool::wait
  -------------------------------------------------------
  set tp [tpool::create -maxworkers 1]
  for {set i 1} {$i < 10} {incr i} {
  puts [tpool::post -nowait $tp [subst {
  puts $i:start
  after 1000
  puts $i:end
  }]]
  }
  after 5000
  # jobs 1,2,3 was already done here
  tpool::cancel $tp {1 2 3} uncanceled
  if {$uncanceled ne {1 2 3}} {
  # may be $uncanceled is {1 1 1 2 2 2 3 3 3}
  error "uncanceled is $uncanceled"
  }


  In this code, only one worker thread is worked.
  So posted jobs are eval one by one.
  After The 1, 2 and 3 jobs are finished, tpool::cancel 
  is called. So 1,2,3 jobs can't be canceled.
  tpool::cancel returns empty list and should set a list
  of uncanceled jobs (1,2 and 3) to "uncanceled" variable.
  But "uncanceled" variable is {1 1 1 2 2 2 3 3 3} 
  in this case.


  There isn't a test, so I have no confidence 
  in detail of specifications... 
  But I try to make a pach. see also that.

  thanks.


tkt_uuid: 1516450fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Fixed
title: Compiler warnings building on x86_64
comment:
  Building on a SUSE 10.1 against Tcl 8.5 (cvs) i get
  compiler warnings for some code:

  ./generic/threadSvCmd.c: In function
  ‘SvAllocateContainers’:
  ./generic/threadSvCmd.c:881: warning: cast from pointer
  to integer of different size
  ./generic/threadSvCmd.c:881: warning: cast from pointer
  to integer of different size

  dkf suggested this as a fix in the chat (and it
  silences the warning):
  static void
  SvAllocateContainers(bucketPtr)
      Bucket *bucketPtr;
  {
      Container tmp[2];
      size_t objSizePlusPadding =
  (size_t)(((char*)(tmp+1))-(char*)tmp);
      /* 
       size_t objSizePlusPadding =
  ((int)(&(tmp[1]))-(int)(&(tmp[0])));
      */

  ...


tkt_uuid: 1516686fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 8
foundin: None
resolution: Fixed
title: Crash with Tcl 8.5 on x86_64
comment:
  I see a segfault when compiling Thread (cvs) against
  Tcl 8.5 (cvs) on my SUSE 10.1 x86_64 machine.

  The following script crashes Tcl.
  (basically from the testsuit thread-4.4)
  load ./libthread2.6.3.so Thread
  set tid [thread::create -joinable {set x 5}]
  thread::join $tid

  The crash does not happen in an --enable-symbols build.

  I have linked tcl and thread with efence to find
  something, and run the script inside gdb.

  schlenk@chronos:~/devel/thread> gdb ../tcl/efence/tclsh
  GNU gdb 6.4
  This GDB was configured as "x86_64-suse-linux"...Using
  host libthread_db library "/lib64/libthread_db.so.1".

  (gdb) run
  Starting program: /home/schlenk/devel/tcl/efence/tclsh
  [Thread debugging using libthread_db enabled]
  [New Thread 47191154113392 (LWP 9563)]

    Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce
  Perens <bruce@perens.com>
  [New Thread 1082132800 (LWP 9566)]
  % source crash.tcl
  [New Thread 1090525504 (LWP 9567)]
  [Thread 1090525504 (zombie) exited]

  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 47191154113392 (LWP 9563)]
  TclEvalObjvInternal (interp=0x2aeb8bffbc70, objc=2,
  objv=0x7fff1f2c5320,
      command=0x2aeb8c06403d "thread::join $tid\n",
  length=18, flags=0)
      at
  /home/schlenk/devel/tcl/unix/../generic/tclBasic.c:3394
  3394        if (!(cmdPtr->flags & CMD_IS_DELETED)) {

  This is the resulting stack trace:

  #0  TclEvalObjvInternal (interp=0x2b5c2cf2bc70, objc=2,
  objv=0x7fff7e3933f0,
      command=0x2b5c2cf9383d "thread::join $tid\n",
  length=18, flags=0)
      at
  /home/schlenk/devel/tcl/unix/../generic/tclBasic.c:3394
  #1  0x0000000000467cd0 in Tcl_EvalEx
  (interp=0x2b5c2cf2bc70,
      script=0x2b5c2cf937f0 "load ./libthread2.6.3.so
  Thread\nset tid [thread::create -joinable {set x
  5}]\nthread::join $tid\n",
      numBytes=<value optimized out>, flags=<value
  optimized out>)
      at
  /home/schlenk/devel/tcl/unix/../generic/tclBasic.c:3788
  #2  0x000000000042344f in Tcl_FSEvalFileEx
  (interp=0x2b5c2cf2bc70,
      pathPtr=0x2b5c2cf3cf00, encodingName=<value
  optimized out>)
      at
  /home/schlenk/devel/tcl/unix/../generic/tclIOUtil.c:1805
  #3  0x0000000000479de2 in Tcl_SourceObjCmd
  (dummy=<value optimized out>,
      interp=0x2b5c2cf2bc70, objc=<value optimized out>,
  objv=0x2b5c2cf45078)
      at
  /home/schlenk/devel/tcl/unix/../generic/tclCmdMZ.c:959
  #4  0x00000000004676b2 in TclEvalObjvInternal
  (interp=0x2b5c2cf2bc70, objc=2,
      objv=0x2b5c2cf45078, command=0x0, length=0, flags=0)
      at
  /home/schlenk/devel/tcl/unix/../generic/tclBasic.c:3381
  #5  0x0000000000497bdd in TclExecuteByteCode
  (interp=0x2b5c2cf2bc70,
      codePtr=0x2b5c2cf20e70)
      at
  /home/schlenk/devel/tcl/unix/../generic/tclExecute.c:1795
  #6  0x000000000049edcf in TclCompEvalObj
  (interp=0x2b5c2cf2bc70,
      objPtr=0x2b5c2cf41e80)
      at
  /home/schlenk/devel/tcl/unix/../generic/tclExecute.c:1003
  ---Type <return> to continue, or q <return> to quit---
  #7  0x0000000000468340 in Tcl_EvalObjEx
  (interp=0x2b5c2cf2bc70,
      objPtr=0x5e0b38, flags=131072)
      at
  /home/schlenk/devel/tcl/unix/../generic/tclBasic.c:4058
  #8  0x00000000004a45db in Tcl_RecordAndEvalObj
  (interp=0x2b5c2cf2bc70,
      cmdPtr=0x2b5c2cf41e80, flags=131072)
      at
  /home/schlenk/devel/tcl/unix/../generic/tclHistory.c:146
  #9  0x00000000004263d2 in Tcl_Main (argc=754371952,
  argv=0x2b5c2cfc7770,
      appInitProc=0x412ac0 <Tcl_AppInit>)
      at
  /home/schlenk/devel/tcl/unix/../generic/tclMain.c:546
  #10 0x0000000000412b10 in main (argc=754105456,
  argv=0x5e0b38)
      at /home/schlenk/devel/tcl/unix/../unix/tclAppInit.c:87


tkt_uuid: 1521416fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 9 Immediate
foundin: obsolete: 8.4.19
resolution: Out of Date
title: thread::release on win32 does not release all memory
comment:
  The original usenet posting - 
   All 5 messages in topic - view as tree

  From:usenet....@googlemail.com - view profile
  Date:Tues, Jul 11 2006 11:01 am
  Email: usenet....@googlemail.com
  Groups: comp.lang.tcl
  Not yet rated
  Rating: 
  show options

  Reply | Reply to Author | Forward | Print | Individual
  Message | Show original | Report Abuse | Find messages
  by this author

  I am running tcl 8.4 on Windows XP Pro 2002, SP2.
  The simple script below fails on thread::create right
  under 12,000
  iterations.

  Attempts to create any more threads fail in the same
  shell once a call
  to
  thread::create fails.
  Restarting tclsh and rerunning seems to work fine
  within the limits
  mentioned
  above.

  Would anyone know the reason this would fail?

  ---------------
  tclsh
  package require Thread
  set i 1
  while { 1 } {
    set id [thread::create]
    thread::release $id
    puts -nonewline " $i "
    flush stdout
    update
    incr i

  } 




  From:David Gravereaux - view profile
  Date:Wed, Jul 12 2006 12:17 pm
  Email: David Gravereaux <davyg...@pobox.com>
  Groups: comp.lang.tcl
  Not yet rated
  Rating: 
  show options

  Reply | Reply to Author | Forward | Print | Individual
  Message | Show original | Report Abuse | Find messages
  by this author

  -----BEGIN PGP SIGNED MESSAGE-----
  Hash: SHA1

  joe,

  I ran your script this time and I see what's going on :)

  The Tclsh process runs out of virtual memory space! 
  Not committed
  memory..  True VM allocations.  I even tried the old
  fashioned way with
  thread::wait and thread::unwind that I personally know
  for a fact do not
  leak handles..  The issue is not a handle leak.  The
  issue is not
  committed memory (apparently), but it appears that for
  each thread
  created, a slice of VM is given to it permanently and
  that slice isn't
  recouped (though it appears to have been uncommitted).

  Joe, insert your script as a new bug.  There's
  something going on that's
  a bit deeper than proper handle management.

  the Old way (that has the same behavior):

  package require Thread
  set i 1
  while { 1 } {
    set id [thread::create {thread::wait}]
    thread::send -async $id {thread::unwind}
    puts -nonewline " $i "
    flush stdout
    update
    incr i

  }


tkt_uuid: 1523697fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 6
foundin: obsolete: 8.5a5
resolution: Fixed
title: Crash using clock commands in a Thread using VFS
comment:
  Hi guys,

  I'm using Tcl 8.5a4 with Thread 2.6.3 in a housemade
  TclKit with threads enabled (of course) and VFS 1.3
  (including the patch Jeff Hobbs did on 2006-05-26).

  When running the next code with the Tcl/Tk without
  using VFS it runs ok, but when we execute this code in
  a Threaded TclKit it crashes (sorry, but I don't see
  any error message).

  if {[catch {
      package require Thread
  }]} {
      load thread.dll
  }

  set threadIds {}
  set x 0

  while {$x < 10} {
      lappend threadIds [thread::create]
      incr x
  }

  foreach threadId $threadIds {
      thread::send -async $threadId "clock format [clock
  seconds] -format \"%Y/%m/%d %H:%M:%S\""
  }

  To me looks like a VFS/Thread problem or maybe a clock
  problem (I've tested with ActiveState 8.4.13 BaseKit
  and seems to work fine).

  If you need anything else, please don't hesitate to
  contact me.

  Best Regards,
  Carlos Tasada.


tkt_uuid: 1575342fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 9 Immediate
foundin: obsolete: 8.5a6
resolution: Fixed
title: tsv keyed list segfault
comment:
  Tclsh 8.5a5 on Windows, 8.5a4 on FreeBSD
  reliably segfault with the following script.

  package require Thread
  tsv::keylset a b c d
  tsv::keylkeys a b x


tkt_uuid: 1578877fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: Wont Fix
title: thread::release treats hanging processes wrongly
comment:
  If you run a process in a thread and try to kill it 
  with thread::release, then the thread ID will be 
  removed from the list even though it remains running, 
  e.g. if it is stuck in an infinite loop.


tkt_uuid: 1603234fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 9 Immediate
foundin: obsolete: 8.4.14
resolution: Fixed
title: Memory leak with thread::transfer
comment:
  I am developing project using Tcl + Thread (BitTorrent tracker). At first I tried to use model where main thread after accepting new connection (using 
  socket -server) transfers connection socket to free thread using thread::transfer. But testing of this model reveals slow memory leak (about 1Mb/5min with requests rate about 100 req/sec). Using Tcl memory debugging (Tcl and Thread built with --enable-symbols=mem) and memory command I found that memory leaks after each thread::transfer call. This observes on latest Tcl/Threads versions as well (tcl8.4.14 and thread2.6.5) compiled on Solaris 9/i386 using GCC 3.3.2.

  Is this a known issue ? Is thread::transfer requires some extra dealing with transferred filedescriptors before or after transfer ?

  This is a small test:

  #!/usr/local/bin/tclsh

  package require Thread

  proc transfer {channel} {
      global tid

      puts [memory info]
      thread::transfer $tid $channel
      thread::send -async $tid "close $channel"
  }

  proc accept {channel client_addr client_port} {
      after idle [list transfer $channel]
  }

  set tid [thread::create -joinable thread::wait]

  socket -server accept 9999

  thread::wait

  Field "current bytes allocated" increased by 32 bytes after each incoming connection.


tkt_uuid: 1634129fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.5a5
resolution: Works For Me
title: bus error during gmake test
comment:
  tcl and thread configured with 
  ../configure --prefix=/projects/sprs_lwv/tcl85 \--enable-shared --enable-symbols --enable-threads \
          --enable-64bit

  on sparc solaris 9 using sun c compiler.
  Here's the result of the gmake test:

  Tcl 8.5a6 tests running in interp:  /vol/tclsrcsol/tcl85/tcl/unix/tclsh
  Tests running in working dir:  /vol/tclsrcsol/tcl85/thread/tests
  Only running tests that match:  *
  Skipping test files that match:  l.*.test
  Only sourcing test files that match:  *.test
  Tests began at Fri Jan 12 10:22:43 EST 2007
  Thread 2.6.5
  Mainthread id is tid1
  thread.test
  gmake: *** [test] Bus Error (core dumped)
  and here's the dbx output:

  Reading tclsh8.5
  core file header read successfully
  Reading ld.so.1
  Reading libtcl8.5.so
  Reading libdl.so.1
  Reading libsocket.so.1
  Reading libnsl.so.1
  Reading libpthread.so.1
  Reading libm.so.1
  Reading libc.so.1
  Reading libmp.so.2
  Reading libc_psr.so.1
  Reading libthread.so.1
  Reading libthread2.6.5.so
  detected a multithreaded program
  t@1 (l@1) terminated by signal BUS (invalid address alignment)
  0xffffffff7dd0b83c: _thrp_join+0x01ac:  stx     %l2, [%i2]
  Current function is Tcl_JoinThread
    166       result = pthread_join((pthread_t) threadId, (void**) state);
  (dbx 1) where
  current thread: t@1
    [1] _thrp_join(0x0, 0x0, 0xffffffff7fff0e54, 0x1, 0xffffffff7fff0cb8, 0xffffffff7fff0cc0), at 0xffffffff7dd0b83c
  =>[2] Tcl_JoinThread(threadId = 0x7, state = 0xffffffff7fff0e54), line 166 in "tclUnixThrd.c"
    [3] ThreadJoin(interp = 0x1000428b0, thrId = 0x7), line 2062 in "threadCmd.c"
    [4] ThreadJoinObjCmd(dummy = (nil), interp = 0x1000428b0, objc = 2, objv = 0xffffffff7fff13f8), line 1172 in "threadCmd.c"
    [5] TclEvalObjvInternal(interp = 0x1000428b0, objc = 2, objv = 0xffffffff7fff13f8, command = 0x1003f800c "thread::join $tid]\n    ThreadReap\n    set c\n", length = 17, flags = 0), line 3659 in "tclBasic.c"
    [6] TclEvalEx(interp = 0x1000428b0, script = 0x1003f800c "thread::join $tid]\n    ThreadReap\n    set c\n", numBytes = 17, flags = 0, line = 4), line 4263 in "tclBasic.c"
    [7] TclSubstTokens(interp = 0x1000428b0, tokenPtr = 0xffffffff7fff1cd0, count = 1, tokensLeftPtr = (nil), line = 4), line 2098 in "tclParse.c"
    [8] TclEvalEx(interp = 0x1000428b0, script = 0x1003f7fc0 "\n    ThreadReap\n    set tid [thread::create -joinable {set x 5}]\n    set c [thread::join $tid]\n    ThreadReap\n    set c\n", numBytes = 120, flags = 262144, line = 4), line 4128 in "tclBasic.c"
    [9] Tcl_EvalEx(interp = 0x1000428b0, script = 0x1003f7fc0 "\n    ThreadReap\n    set tid [thread::create -joinable {set x 5}]\n    set c [thread::join $tid]\n    ThreadReap\n    set c\n", numBytes = 120, flags = 262144), line 3934 in "tclBasic.c"
    [10] TclEvalObjEx(interp = 0x1000428b0, objPtr = 0x1003cb5f0, flags = 262144, invoker = (nil), word = 0), line 4652 in "tclBasic.c"
    [11] Tcl_EvalObjEx(interp = 0x1000428b0, objPtr = 0x1003cb5f0, flags = 262144), line 4516 in "tclBasic.c"
    [12] Tcl_UplevelObjCmd(dummy = (nil), interp = 0x1000428b0, objc = 1, objv = 0x100046ed8), line 889 in "tclProc.c"
    [13] TclEvalObjvInternal(interp = 0x1000428b0, objc = 3, objv = 0x100046ec8, command = (nil), length = 0, flags = 0), line 3659 in "tclBasic.c"
    [14] TclExecuteByteCode(interp = 0x1000428b0, codePtr = 0x1004046d0), line 1832 in "tclExecute.c"
    [15] TclCompEvalObj(interp = 0x1000428b0, objPtr = 0x1000c8d50, invoker = (nil), word = 0), line 1014 in "tclExecute.c"
    [16] TclObjInterpProcCore(interp = 0x1000428b0, framePtr = 0x100046d48, procNameObj = 0x1003ce860, isLambda = 0, skip = 1, errorProc = 0xffffffff7f17d0a8 = &`libtcl8.5.so`tclProc.c`MakeProcError(Tcl_Interp *interp, Tcl_Obj *procNameObj)), line 1501 in "tclProc.c"
    [17] ObjInterpProcEx(clientData = 0x100178790, interp = 0x1000428b0, objc = 3, objv = 0x1003f9d90, isLambda = 0, errorProc = 0xffffffff7f17d0a8 = &`libtcl8.5.so`tclProc.c`MakeProcError(Tcl_Interp *interp, Tcl_Obj *procNameObj)), line 1254 in "tclProc.c"
    [18] TclObjInterpProc(clientData = 0x100178790, interp = 0x1000428b0, objc = 3, objv = 0x1003f9d90), line 1196 in "tclProc.c"
    [19] TclEvalObjvInternal(interp = 0x1000428b0, objc = 3, objv = 0x1003f9d90, command = 0xffffffff7f2fd7a0 "", length = 0, flags = 262144), line 3659 in "tclBasic.c"
    [20] Tcl_EvalObjv(interp = 0x1000428b0, objc = 3, objv = 0x1003f9d90, flags = 262144), line 3779 in "tclBasic.c"
    [21] TclEvalObjEx(interp = 0x1000428b0, objPtr = 0x1003cebc0, flags = 262144, invoker = (nil), word = 0), line 4609 in "tclBasic.c"
    [22] Tcl_EvalObjEx(interp = 0x1000428b0, objPtr = 0x1003cebc0, flags = 262144), line 4516 in "tclBasic.c"
    [23] Tcl_UplevelObjCmd(dummy = (nil), interp = 0x1000428b0, objc = 1, objv = 0x100046d40), line 889 in "tclProc.c"
    [24] TclEvalObjvInternal(interp = 0x1000428b0, objc = 3, objv = 0x100046d30, command = (nil), length = 0, flags = 0), line 3659 in "tclBasic.c"
    [25] TclExecuteByteCode(interp = 0x1000428b0, codePtr = 0x1002b7bf0), line 1832 in "tclExecute.c"
    [26] TclCompEvalObj(interp = 0x1000428b0, objPtr = 0x1000ca940, invoker = (nil), word = 0), line 1014 in "tclExecute.c"
    [27] TclObjInterpProcCore(interp = 0x1000428b0, framePtr = 0x100046b78, procNameObj = 0x1003cee00, isLambda = 0, skip = 1, errorProc = 0xffffffff7f17d0a8 = &`libtcl8.5.so`tclProc.c`MakeProcError(Tcl_Interp *interp, Tcl_Obj *procNameObj)), line 1501 in "tclProc.c"
    [28] ObjInterpProcEx(clientData = 0x10016c900, interp = 0x1000428b0, objc = 3, objv = 0x1003f9690, isLambda = 0, errorProc = 0xffffffff7f17d0a8 = &`libtcl8.5.so`tclProc.c`MakeProcError(Tcl_Interp *interp, Tcl_Obj *procNameObj)), line 1254 in "tclProc.c"
    [29] TclObjInterpProc(clientData = 0x10016c900, interp = 0x1000428b0, objc = 3, objv = 0x1003f9690), line 1196 in "tclProc.c"
    [30] TclEvalObjvInternal(interp = 0x1000428b0, objc = 3, objv = 0x1003f9690, command = 0xffffffff7f2fd7a0 "", length = 0, flags = 262144), line 3659 in "tclBasic.c"
    [31] Tcl_EvalObjv(interp = 0x1000428b0, objc = 3, objv = 0x1003f9690, flags = 262144), line 3779 in "tclBasic.c"
    [32] TclEvalObjEx(interp = 0x1000428b0, objPtr = 0x1003ce470, flags = 262144, invoker = (nil), word = 0), line 4609 in "tclBasic.c"
    [33] Tcl_EvalObjEx(interp = 0x1000428b0, objPtr = 0x1003ce470, flags = 262144), line 4516 in "tclBasic.c"
    [34] Tcl_UplevelObjCmd(dummy = (nil), interp = 0x1000428b0, objc = 1, objv = 0x100046b70), line 889 in "tclProc.c"
    [35] TclEvalObjvInternal(interp = 0x1000428b0, objc = 3, objv = 0x100046b60, command = (nil), length = 0, flags = 0), line 3659 in "tclBasic.c"
    [36] TclExecuteByteCode(interp = 0x1000428b0, codePtr = 0x1003ffd20), line 1832 in "tclExecute.c"
    [37] TclCompEvalObj(interp = 0x1000428b0, objPtr = 0x1000ca880, invoker = (nil), word = 0), line 1014 in "tclExecute.c"
    [38] TclObjInterpProcCore(interp = 0x1000428b0, framePtr = 0x100045920, procNameObj = 0x1003cba10, isLambda = 0, skip = 1, errorProc = 0xffffffff7f17d0a8 = &`libtcl8.5.so`tclProc.c`MakeProcError(Tcl_Interp *interp, Tcl_Obj *procNameObj)), line 1501 in "tclProc.c"
    [39] ObjInterpProcEx(clientData = 0x100178210, interp = 0x1000428b0, objc = 5, objv = 0xffffffff7fff8588, isLambda = 0, errorProc = 0xffffffff7f17d0a8 = &`libtcl8.5.so`tclProc.c`MakeProcError(Tcl_Interp *interp, Tcl_Obj *procNameObj)), line 1254 in "tclProc.c"
    [40] TclObjInterpProc(clientData = 0x100178210, interp = 0x1000428b0, objc = 5, objv = 0xffffffff7fff8588), line 1196 in "tclProc.c"
    [41] InvokeImportedCmd(clientData = 0x1001aac80, interp = 0x1000428b0, objc = 5, objv = 0xffffffff7fff8588), line 1892 in "tclNamesp.c"
    [42] TclEvalObjvInternal(interp = 0x1000428b0, objc = 5, objv = 0xffffffff7fff8588, command = 0x1003e88d3 "test thread-4.4 {thread::create - create joinable thread} {\n    ThreadReap\n    set tid [thread::create -joinable {set x 5}]\n    set c [thread::join $tid]\n    ThreadReap\n    set c\n} {0}\n\ntest thread-4.5 {thread::create - join detached thread} {\n    ThreadReap\n    set tid [thread::create]\n    thread::send -async $tid {after 1000 ; thread::release}\n    catch {set res [thread::join $tid]} msg\n    ThreadReap\n    lrange $msg 0 2\n} {cannot join thread}\n\ntest thread-5.0 {thread::release} {\n    ThreadReap\n    set ti" ..., length = 185, flags = 0), line 3659 in "tclBasic.c"
    [43] TclEvalEx(interp = 0x1000428b0, script = 0x1003e7d90 "# Commands covered:  thread\n#\n# This file contains a collection of tests for one or more of the Tcl\n# built-in commands.  Sourcing this file into Tcl runs the tests and\n# generates output for errors.  No output means no errors were found.\n#\n# Copyright (c) 1996 Sun Microsystems, Inc.\n# Copyright (c) 1998-2000 Scriptics Corporation.\n# Copyright (c) 2002 ActiveState Corporation.\n#\n# See the file "license.terms" for information on usage and redistribution\n# of this file, and for a DISCLAIMER OF ALL WARRANTIES." ..., numBytes = 33216, flags = 0, line = 97), line 4263 in "tclBasic.c"
    [44] Tcl_EvalEx(interp = 0x1000428b0, script = 0x1003e7d90 "# Commands covered:  thread\n#\n# This file contains a collection of tests for one or more of the Tcl\n# built-in commands.  Sourcing this file into Tcl runs the tests and\n# generates output for errors.  No output means no errors were found.\n#\n# Copyright (c) 1996 Sun Microsystems, Inc.\n# Copyright (c) 1998-2000 Scriptics Corporation.\n# Copyright (c) 2002 ActiveState Corporation.\n#\n# See the file "license.terms" for information on usage and redistribution\n# of this file, and for a DISCLAIMER OF ALL WARRANTIES." ..., numBytes = 33216, flags = 0), line 3934 in "tclBasic.c"
    [45] Tcl_FSEvalFileEx(interp = 0x1000428b0, pathPtr = 0x1003caed0, encodingName = (nil)), line 1812 in "tclIOUtil.c"
    [46] Tcl_SourceObjCmd(dummy = (nil), interp = 0x1000428b0, objc = 2, objv = 0x100045910), line 959 in "tclCmdMZ.c"
    [47] TclEvalObjvInternal(interp = 0x1000428b0, objc = 2, objv = 0x100045910, command = (nil), length = 0, flags = 0), line 3659 in "tclBasic.c"
    [48] TclExecuteByteCode(interp = 0x1000428b0, codePtr = 0x1003a7e20), line 1832 in "tclExecute.c"
    [49] TclCompEvalObj(interp = 0x1000428b0, objPtr = 0x1003cb3b0, invoker = 0xffffffff7fffba40, word = 1), line 1014 in "tclExecute.c"
    [50] TclEvalObjEx(interp = 0x1000428b0, objPtr = 0x1003cb3b0, flags = 0, invoker = 0xffffffff7fffba40, word = 1), line 4737 in "tclBasic.c"
    [51] Tcl_CatchObjCmd(dummy = (nil), interp = 0x1000428b0, objc = 3, objv = 0x1000458f8), line 249 in "tclCmdAH.c"
    [52] TclEvalObjvInternal(interp = 0x1000428b0, objc = 3, objv = 0x1000458f8, command = (nil), length = 0, flags = 0), line 3659 in "tclBasic.c"
    [53] TclExecuteByteCode(interp = 0x1000428b0, codePtr = 0x1003dce80), line 1832 in "tclExecute.c"
    [54] TclCompEvalObj(interp = 0x1000428b0, objPtr = 0x1003cb500, invoker = 0xffffffff7fffc370, word = 3), line 1014 in "tclExecute.c"
    [55] TclEvalObjEx(interp = 0x1000428b0, objPtr = 0x1003cb500, flags = 0, invoker = 0xffffffff7fffc370, word = 3), line 4737 in "tclBasic.c"
    [56] Tcl_ForeachObjCmd(dummy = (nil), interp = 0x1000428b0, objc = 4, objv = 0xffffffff7fffc4b8), line 1828 in "tclCmdAH.c"
    [57] TclEvalObjvInternal(interp = 0x1000428b0, objc = 4, objv = 0xffffffff7fffc4b8, command = 0x100063d43 "foreach file [lsort [::tcltest::getMatchingFiles]] {\n    set tail [file tail $file]\n    puts stdout $tail\n    if {[catch {source $file} msg]} {\n        puts stdout $msg\n    }\n}\n\n# Cleanup\nputs stdout "\nTests ended at [eval $timeCmd]"\n::tcltest::cleanupTests 1\n\nreturn\n\n", length = 177, flags = 0), line 3659 in "tclBasic.c"
    [58] TclEvalEx(interp = 0x1000428b0, script = 0x1000636c0 "# all.tcl --\n#\n# This file contains a top-level script to run all of the Tcl\n# tests.  Execute it by invoking "source all.test" when running tcltest\n# in this directory.\n#\n# Copyright (c) 1998-1999 by Scriptics Corporation.\n# All rights reserved.\n# \n# RCS: @(#) $Id: all.tcl,v 1.5 2004/12/18 13:26:03 vasiljevic Exp $\n\npackage require tcltest\nnamespace import -force ::tcltest::*\n\nset ::tcltest::testSingleFile false\nset ::tcltest::testsDirectory [file dir [info script]]\n\n# We need to ensure that the testsDirec" ..., numBytes = 1937, flags = 0, line = 53), line 4263 in "tclBasic.c"
    [59] Tcl_EvalEx(interp = 0x1000428b0, script = 0x1000636c0 "# all.tcl --\n#\n# This file contains a top-level script to run all of the Tcl\n# tests.  Execute it by invoking "source all.test" when running tcltest\n# in this directory.\n#\n# Copyright (c) 1998-1999 by Scriptics Corporation.\n# All rights reserved.\n# \n# RCS: @(#) $Id: all.tcl,v 1.5 2004/12/18 13:26:03 vasiljevic Exp $\n\npackage require tcltest\nnamespace import -force ::tcltest::*\n\nset ::tcltest::testSingleFile false\nset ::tcltest::testsDirectory [file dir [info script]]\n\n# We need to ensure that the testsDirec" ..., numBytes = 1937, flags = 0), line 3934 in "tclBasic.c"
    [60] Tcl_FSEvalFileEx(interp = 0x1000428b0, pathPtr = 0x1000332d0, encodingName = (nil)), line 1812 in "tclIOUtil.c"
    [61] Tcl_Main(argc = -1, argv = 0xffffffff7fffcf78, appInitProc = 0x100001e50 = &Tcl_AppInit(Tcl_Interp *interp)), line 441 in "tclMain.c"
    [62] main(argc = 2, argv = 0xffffffff7fffcf68), line 87 in "tclAppInit.c"
  (dbx 2) 


tkt_uuid: 1643367fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.5a5
resolution: Fixed
title: Thread extension cannot compile with VC8
comment:
  I've just upgraded my system to use VC8 and the Thread extension doesn't compile :(

  The error that I get is:

  makefile.vc(12) : fatal error U1050:
  You'll need to run vcvars32.bat from Developer Studio, first, to setup
  the environment.  Jump to this line to read the new instructions.

  Tcl, Tk and Itcl compiles without problem and I see that some changes has been done to the makefile.vc. Seems that the Thread package is not in sync with the rest.

  Thanks a lot.


tkt_uuid: 1689375fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: None
title: Update VC makefile for Threads (Fix for bug 1643367)
comment:
  The attached patch updates the makefile.vc and rules.vc to be in line with the sampleextension in CVS (plus the changes I have submitted in bug [ 1689286 ] nmakehlp not building on Win32 with VC).

  It also acts as a fix to bug [ 1643367 ].

  Tested with VC6 and VC8 on Windows 2000.  Builds, installs and runs correctly (including running all tests), so far as I can tell ;)

  There are a number of changes:
    - configure.in: note to change DOTVERSION in makefile.vc when you update the version
    - win/thread.rc: the sampleextension makefile.vc provides different variables/defines to rc
    - tests/thread.test: tcl_PatchLevel ==> tcl_patchLevel
    - win/makefile.vc, win/nmakehlp.c and win/rules.vc: added, based on sampleextension with minimal changes needed to make it work with threads extension

  The files win/vc/makefile.vc, win/vc/nmakehlp.c, win/vc/pkg.vc and win/vc/rules.vc are no longer required and should be deleted.  They have effectively been moved to win/ and replaced with updates based on
  sampleextension.  If these files stay in win/vc and get modified to be in a "non-standard" location, then we ensure this pain every time they need to be updated (otherwise we just copy from sampleextension).


tkt_uuid: 1712723fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 9 Immediate
foundin: obsolete: 8.5a7
resolution: Fixed
title: joinable threads die on Solaris 64-bit
comment:
  Platform: sparc solaris 9
  Compiler: Forte Developer 7 C 5.4 2002/03/09
  Tcl: cvs head located on tcl.activestate.com ftp site - titled tcl-20070503.tar.gz
  Thread: cvs head located on tcl.activestate.com ftp site - titled thread-20070503.tar.gz
  Configuration parms (for both tcl and thread): \"'--prefix=/projects/sprs_lwv/tcl85' '--enable-shared' '--enable-symbols' '--enable-stubs' '--enable-64bit' '--enable-threads'

  After successfully running a fresh configure/build/test/install of the may 3 tcl, I proceeded to build a fresh copy of the may 3 thread. The configure and build worked fine, then I encountered:
  Tests began at Fri May 04 08:52:33 EDT 2007
  Thread 2.6.5
  Mainthread id is tid1
  thread.test
  gmake: *** [test] Bus Error (core dumped)
   $ dbx /vol/tclsrcsol/tcl85/tcl/unix/tclsh core
  For information about new features see `help changes'
  To remove this message, put `dbxenv suppress_startup_message 7.0' in your .dbxrc
  Reading tclsh
  core file header read successfully
  Reading ld.so.1
  Reading libtcl8.5.so
  Reading libdl.so.1
  Reading libsocket.so.1
  Reading libnsl.so.1
  Reading libpthread.so.1
  Reading libm.so.1
  Reading libc.so.1
  Reading libmp.so.2
  Reading libc_psr.so.1
  Reading libthread.so.1
  Reading libthread2.6.5.so
  detected a multithreaded program
  t@1 (l@1) terminated by signal BUS (invalid address alignment)
  0xffffffff7dd0b7f4: _thrp_join+0x01ac:  stx     %l2, [%i2]
  Current function is Tcl_JoinThread
    166       result = pthread_join((pthread_t) threadId, (void**) state);
  (dbx 1) print threadId                                                
  threadId = 0x7
  (dbx 2) print state   
  state = 0xffffffff7fff19a4
  (dbx 3) where 
  current thread: t@1
    [1] _thrp_join(0x0, 0x0, 0xffffffff7fff19a4, 0x1, 0xffffffff7fff1808, 0xffffffff7fff1810), at 0xffffffff7dd0b7f4
  =>[2] Tcl_JoinThread(threadId = 0x7, state = 0xffffffff7fff19a4), line 166 in "tclUnixThrd.c"
    [3] ThreadJoin(interp = 0x1000428c0, thrId = 0x7), line 2062 in "threadCmd.c"
    [4] ThreadJoinObjCmd(dummy = (nil), interp = 0x1000428c0, objc = 2, objv = 0xffffffff7fff1f48), line 1172 in "threadCmd.c"
    [5] TclEvalObjvInternal(interp = 0x1000428c0, objc = 2, objv = 0xffffffff7fff1f48, command = 0x1003bc6bc "thread::join $tid]\n    ThreadReap\n    set c\n", length = 17, flags = 0), line 3617 in "tclBasic.c"
    [6] TclEvalEx(interp = 0x1000428c0, script = 0x1003bc6bc "thread::join $tid]\n    ThreadReap\n    set c\n", numBytes = 17, flags = 0, line = 4), line 4222 in "tclBasic.c"
    [7] TclSubstTokens(interp = 0x1000428c0, tokenPtr = 0xffffffff7fff2820, count = 1, tokensLeftPtr = (nil), line = 4), line 2099 in "tclParse.c"
    [8] TclEvalEx(interp = 0x1000428c0, script = 0x1003bc670 "\n    ThreadReap\n    set tid [thread::create -joinable {set x 5}]\n    set c [thread::join $tid]\n    ThreadReap\n    set c\n", numBytes = 120, flags = 262144, line = 4), line 4087 in "tclBasic.c"
    [9] Tcl_EvalEx(interp = 0x1000428c0, script = 0x1003bc670 "\n    ThreadReap\n    set tid [thread::create -joinable {set x 5}]\n    set c [thread::join $tid]\n    ThreadReap\n    set c\n", numBytes = 120, flags = 262144), line 3892 in "tclBasic.c"
    [10] TclEvalObjEx(interp = 0x1000428c0, objPtr = 0x1002075b0, flags = 262144, invoker = (nil), word = 0), line 4592 in "tclBasic.c"
    [11] Tcl_EvalObjEx(interp = 0x1000428c0, objPtr = 0x1002075b0, flags = 262144), line 4475 in "tclBasic.c"
    [12] Tcl_UplevelObjCmd(dummy = (nil), interp = 0x1000428c0, objc = 1, objv = 0x100047008), line 900 in "tclProc.c"
    [13] TclExecuteByteCode(interp = 0x1000428c0, codePtr = 0x100418760), line 1834 in "tclExecute.c"
    [14] TclCompEvalObj(interp = 0x1000428c0, objPtr = 0x1000c8520, invoker = (nil), word = 0), line 996 in "tclExecute.c"
    [15] TclObjInterpProcCore(interp = 0x1000428c0, framePtr = 0x100046e78, procNameObj = 0x1003d3030, isLambda = 0, skip = 1, errorProc = 0xffffffff7f18d0e0 = &`libtcl8.5.so`tclProc.c`MakeProcError(Tcl_Interp *interp, Tcl_Obj *procNameObj)), line 1535 in "tclProc.c"
    [16] ObjInterpProcEx(clientData = 0x100095690, interp = 0x1000428c0, objc = 3, objv = 0x10040d420, isLambda = 0, errorProc = 0xffffffff7f18d0e0 = &`libtcl8.5.so`tclProc.c`MakeProcError(Tcl_Interp *interp, Tcl_Obj *procNameObj)), line 1283 in "tclProc.c"
    [17] TclObjInterpProc(clientData = 0x100095690, interp = 0x1000428c0, objc = 3, objv = 0x10040d420), line 1213 in "tclProc.c"
    [18] TclEvalObjvInternal(interp = 0x1000428c0, objc = 3, objv = 0x10040d420, command = 0xffffffff7f1df360 "", length = 0, flags = 262144), line 3617 in "tclBasic.c"
    [19] Tcl_EvalObjv(interp = 0x1000428c0, objc = 3, objv = 0x10040d420, flags = 262144), line 3737 in "tclBasic.c"
    [20] TclEvalObjEx(interp = 0x1000428c0, objPtr = 0x1003d1e90, flags = 262144, invoker = (nil), word = 0), line 4563 in "tclBasic.c"
    [21] Tcl_EvalObjEx(interp = 0x1000428c0, objPtr = 0x1003d1e90, flags = 262144), line 4475 in "tclBasic.c"
    [22] Tcl_UplevelObjCmd(dummy = (nil), interp = 0x1000428c0, objc = 1, objv = 0x100046e70), line 900 in "tclProc.c"
    [23] TclExecuteByteCode(interp = 0x1000428c0, codePtr = 0x1002b9e00), line 1834 in "tclExecute.c"
    [24] TclCompEvalObj(interp = 0x1000428c0, objPtr = 0x1000c83a0, invoker = (nil), word = 0), line 996 in "tclExecute.c"
    [25] TclObjInterpProcCore(interp = 0x1000428c0, framePtr = 0x100046ca8, procNameObj = 0x1003d27c0, isLambda = 0, skip = 1, errorProc = 0xffffffff7f18d0e0 = &`libtcl8.5.so`tclProc.c`MakeProcError(Tcl_Interp *interp, Tcl_Obj *procNameObj)), line 1535 in "tclProc.c"
    [26] ObjInterpProcEx(clientData = 0x10010d160, interp = 0x1000428c0, objc = 3, objv = 0x10040d860, isLambda = 0, errorProc = 0xffffffff7f18d0e0 = &`libtcl8.5.so`tclProc.c`MakeProcError(Tcl_Interp *interp, Tcl_Obj *procNameObj)), line 1283 in "tclProc.c"
    [27] TclObjInterpProc(clientData = 0x10010d160, interp = 0x1000428c0, objc = 3, objv = 0x10040d860), line 1213 in "tclProc.c"
    [28] TclEvalObjvInternal(interp = 0x1000428c0, objc = 3, objv = 0x10040d860, command = 0xffffffff7f1df360 "", length = 0, flags = 262144), line 3617 in "tclBasic.c"
    [29] Tcl_EvalObjv(interp = 0x1000428c0, objc = 3, objv = 0x10040d860, flags = 262144), line 3737 in "tclBasic.c"
    [30] TclEvalObjEx(interp = 0x1000428c0, objPtr = 0x1003d2d60, flags = 262144, invoker = (nil), word = 0), line 4563 in "tclBasic.c"
    [31] Tcl_EvalObjEx(interp = 0x1000428c0, objPtr = 0x1003d2d60, flags = 262144), line 4475 in "tclBasic.c"
    [32] Tcl_UplevelObjCmd(dummy = (nil), interp = 0x1000428c0, objc = 1, objv = 0x100046ca0), line 900 in "tclProc.c"
    [33] TclExecuteByteCode(interp = 0x1000428c0, codePtr = 0x100407ea0), line 1834 in "tclExecute.c"
    [34] TclCompEvalObj(interp = 0x1000428c0, objPtr = 0x1000ca950, invoker = (nil), word = 0), line 996 in "tclExecute.c"
    [35] TclObjInterpProcCore(interp = 0x1000428c0, framePtr = 0x100045990, procNameObj = 0x1003cfdf0, isLambda = 0, skip = 1, errorProc = 0xffffffff7f18d0e0 = &`libtcl8.5.so`tclProc.c`MakeProcError(Tcl_Interp *interp, Tcl_Obj *procNameObj)), line 1535 in "tclProc.c"
    [36] ObjInterpProcEx(clientData = 0x100094460, interp = 0x1000428c0, objc = 5, objv = 0xffffffff7fff8bc8, isLambda = 0, errorProc = 0xffffffff7f18d0e0 = &`libtcl8.5.so`tclProc.c`MakeProcError(Tcl_Interp *interp, Tcl_Obj *procNameObj)), line 1283 in "tclProc.c"
    [37] TclObjInterpProc(clientData = 0x100094460, interp = 0x1000428c0, objc = 5, objv = 0xffffffff7fff8bc8), line 1213 in "tclProc.c"
    [38] InvokeImportedCmd(clientData = 0x1001bb190, interp = 0x1000428c0, objc = 5, objv = 0xffffffff7fff8bc8), line 1904 in "tclNamesp.c"
    [39] TclEvalObjvInternal(interp = 0x1000428c0, objc = 5, objv = 0xffffffff7fff8bc8, command = 0x1003e8af3 "test thread-4.4 {thread::create - create joinable thread} {\n    ThreadReap\n    set tid [thread::create -joinable {set x 5}]\n    set c [thread::join $tid]\n    ThreadReap\n    set c\n} {0}\n\ntest thread-4.5 {thread::create - join detached thread} {\n    ThreadReap\n    set tid [thread::create]\n    thread::send -async $tid {after 1000 ; thread::release}\n    catch {set res [thread::join $tid]} msg\n    ThreadReap\n    lrange $msg 0 2\n} {cannot join thread}\n\ntest thread-5.0 {thread::release} {\n    ThreadReap\n    set ti" ..., length = 185, flags = 0), line 3617 in "tclBasic.c"
    [40] TclEvalEx(interp = 0x1000428c0, script = 0x1003e7fb0 "# Commands covered:  thread\n#\n# This file contains a collection of tests for one or more of the Tcl\n# built-in commands.  Sourcing this file into Tcl runs the tests and\n# generates output for errors.  No output means no errors were found.\n#\n# Copyright (c) 1996 Sun Microsystems, Inc.\n# Copyright (c) 1998-2000 Scriptics Corporation.\n# Copyright (c) 2002 ActiveState Corporation.\n#\n# See the file "license.terms" for information on usage and redistribution\n# of this file, and for a DISCLAIMER OF ALL WARRANTIES." ..., numBytes = 33216, flags = 0, line = 97), line 4222 in "tclBasic.c"
    [41] Tcl_EvalEx(interp = 0x1000428c0, script = 0x1003e7fb0 "# Commands covered:  thread\n#\n# This file contains a collection of tests for one or more of the Tcl\n# built-in commands.  Sourcing this file into Tcl runs the tests and\n# generates output for errors.  No output means no errors were found.\n#\n# Copyright (c) 1996 Sun Microsystems, Inc.\n# Copyright (c) 1998-2000 Scriptics Corporation.\n# Copyright (c) 2002 ActiveState Corporation.\n#\n# See the file "license.terms" for information on usage and redistribution\n# of this file, and for a DISCLAIMER OF ALL WARRANTIES." ..., numBytes = 33216, flags = 0), line 3892 in "tclBasic.c"
    [42] Tcl_FSEvalFileEx(interp = 0x1000428c0, pathPtr = 0x1003cf190, encodingName = (nil)), line 1818 in "tclIOUtil.c"
    [43] Tcl_SourceObjCmd(dummy = (nil), interp = 0x1000428c0, objc = 2, objv = 0x100045980), line 953 in "tclCmdMZ.c"
    [44] TclExecuteByteCode(interp = 0x1000428c0, codePtr = 0x1003bbe70), line 1834 in "tclExecute.c"
    [45] TclCompEvalObj(interp = 0x1000428c0, objPtr = 0x1000c9f30, invoker = 0xffffffff7fffbd60, word = 1), line 996 in "tclExecute.c"
    [46] TclEvalObjEx(interp = 0x1000428c0, objPtr = 0x1000c9f30, flags = 0, invoker = 0xffffffff7fffbd60, word = 1), line 4677 in "tclBasic.c"
    [47] Tcl_CatchObjCmd(dummy = (nil), interp = 0x1000428c0, objc = 3, objv = 0x100045968), line 253 in "tclCmdAH.c"
    [48] TclExecuteByteCode(interp = 0x1000428c0, codePtr = 0x1003c1420), line 1834 in "tclExecute.c"
    [49] TclCompEvalObj(interp = 0x1000428c0, objPtr = 0x1003cf7f0, invoker = 0xffffffff7fffc5a0, word = 3), line 996 in "tclExecute.c"
    [50] TclEvalObjEx(interp = 0x1000428c0, objPtr = 0x1003cf7f0, flags = 0, invoker = 0xffffffff7fffc5a0, word = 3), line 4677 in "tclBasic.c"
    [51] Tcl_ForeachObjCmd(dummy = (nil), interp = 0x1000428c0, objc = 4, objv = 0xffffffff7fffc6e8), line 1811 in "tclCmdAH.c"
    [52] TclEvalObjvInternal(interp = 0x1000428c0, objc = 4, objv = 0xffffffff7fffc6e8, command = 0x100063553 "foreach file [lsort [::tcltest::getMatchingFiles]] {\n    set tail [file tail $file]\n    puts stdout $tail\n    if {[catch {source $file} msg]} {\n        puts stdout $msg\n    }\n}\n\n# Cleanup\nputs stdout "\nTests ended at [eval $timeCmd]"\n::tcltest::cleanupTests 1\n\nreturn\n\n", length = 177, flags = 0), line 3617 in "tclBasic.c"
    [53] TclEvalEx(interp = 0x1000428c0, script = 0x100062ed0 "# all.tcl --\n#\n# This file contains a top-level script to run all of the Tcl\n# tests.  Execute it by invoking "source all.test" when running tcltest\n# in this directory.\n#\n# Copyright (c) 1998-1999 by Scriptics Corporation.\n# All rights reserved.\n# \n# RCS: @(#) $Id: all.tcl,v 1.5 2004/12/18 13:26:03 vasiljevic Exp $\n\npackage require tcltest\nnamespace import -force ::tcltest::*\n\nset ::tcltest::testSingleFile false\nset ::tcltest::testsDirectory [file dir [info script]]\n\n# We need to ensure that the testsDirec" ..., numBytes = 1937, flags = 0, line = 53), line 4222 in "tclBasic.c"
    [54] Tcl_EvalEx(interp = 0x1000428c0, script = 0x100062ed0 "# all.tcl --\n#\n# This file contains a top-level script to run all of the Tcl\n# tests.  Execute it by invoking "source all.test" when running tcltest\n# in this directory.\n#\n# Copyright (c) 1998-1999 by Scriptics Corporation.\n# All rights reserved.\n# \n# RCS: @(#) $Id: all.tcl,v 1.5 2004/12/18 13:26:03 vasiljevic Exp $\n\npackage require tcltest\nnamespace import -force ::tcltest::*\n\nset ::tcltest::testSingleFile false\nset ::tcltest::testsDirectory [file dir [info script]]\n\n# We need to ensure that the testsDirec" ..., numBytes = 1937, flags = 0), line 3892 in "tclBasic.c"
    [55] Tcl_FSEvalFileEx(interp = 0x1000428c0, pathPtr = 0x100032f80, encodingName = (nil)), line 1818 in "tclIOUtil.c"
    [56] Tcl_Main(argc = -1, argv = 0xffffffff7fffd1a8, appInitProc = 0x100001e58 = &Tcl_AppInit(Tcl_Interp *interp)), line 441 in "tclMain.c"
    [57] main(argc = 2, argv = 0xffffffff7fffd198), line 87 in "tclAppInit.c"
  (dbx 4) 


tkt_uuid: 1716582fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Duplicate
title: Build broken for OPTS=symbols,unchecked
comment:
  The use of -nodefaultlib:msvcrt (in makefile.vc) prevents an unchecked build.

  This flag should not be present; it means that you are linking together objects that use msvcrtd with those that use msvcrt.  While -nodefaultlib gets around linker warnings, this sort of linking is unsafe and can cause subtle and difficult to find bugs.  

  If you build Tcl and Threads with the proper OPTS then
  it shouldn't be required at all.


tkt_uuid: 1716587fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Works For Me
title: Thread tests can't run (bad args from makefile)
comment:
  (A) makefile.vc was updated to the 8.5 build system (ChangeLog 2007/05/03); it calls the test scripts in a new manner (using a -loadfile argument).  tests/all.tcl has not been updated to support this, and as a result the 
  Thread26.dll is never loaded, and the tests cannot run.

  (B) tests/thread.test references tcl_PatchLevel which causes an exception.  Should be tcl_patchLevel

  Patch for these problems and bug [1716582] (Build broken for OPTS=symbols,unchecked) is attached.

  Note: the patch partially reverts the calling of tests\all.tcl in the Makefile.  If you don't do this (and use the -loadfile argument that is has been changed to) then as far as I know you will not be able to build the Threads extension against Tcl 8.4.  That would be a Bad Thing (TM).

  Notes:
  (1) I haven't confirmed that the Thread extension DOES build against 8.4 with this patch (or without it)

  (2) The upgrade referred to in (A) should have fixed [1643367] (Thread extension cannot compile with VC8), but I haven't tested that either.


tkt_uuid: 1745928fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.4.14
resolution: None
title: thread's memory isn't being released
comment:
  when using thread::create, the memory allocated isn't free after the thread ends.
  code:
  -----------------------------
  Microsoft Windows XP [Version 5.1.2600]
  (C) Copyright 1985-2001 Microsoft Corp.

  C:\Documents and Settings\navidor>tclsh84
  % package require Thread
  2.6.5
  % set t [thread::create {puts "a"}]; puts "$t"
  tid00000A38
  % a

  % thread::names
  tid0000012C
  %
  -------------------------------------------
  I'm using winXP, tcl 8.4.14.0
  proccess memory (from windows task manager):
  before requiring Thread package: 2,808k
  after     "          "         : 2,940k
  after creating a thread (and after it ends): 3,716k
  after few minutes of waiting: 84k

  Is it familiar to anyone? any ideas?


tkt_uuid: 1759529fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.5a7
resolution: Fixed
title: Thread tests fails on netbsd
comment:
  while running the tests on netbsd-4, tcl from CVS thread-enabled and thread package from CVS, I get this error:

  emiliano@maq033:~/tcl_sources/thread$ make test 
  TCL_LIBRARY=`echo /home/emiliano/tcl_sources/tcl/library`  TCL_THREAD_LIBRARY=`echo ./lib`  LD_LIBRARY_PATH=".:/home/emiliano/tcl_sources/tcl/unix:"  PATH=".:/home/emiliano/tcl_sources/tcl/unix:/home/emiliano/programas/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/pkg/bin:/usr/pkg/sbin:/usr/games:/usr/local/bin:/usr/local/sbin"  TCLLIBPATH=". ./../lib" /home/emiliano/tcl_sources/tcl/unix/tclsh `echo ./tests/all.tcl` 
  Tcl 8.5a7 tests running in interp:  /home/emiliano/tcl_sources/tcl/unix/tclsh
  Tests running in working dir:  /home/emiliano/tcl_sources/thread/tests
  Only running tests that match:  *
  Skipping test files that match:  l.*.test
  Only sourcing test files that match:  *.test
  Tests began at Tue Jul 24 09:24:21 ART 2007
  Thread 2.6.5
  Mainthread id is tid0xbf800000
  thread.test
  tpool.test
  tsv.test
  ttrace.test

  Tests ended at Tue Jul 24 09:24:36 ART 2007
  all.tcl:        Total   116     Passed  116     Skipped 0       Failed  0
  Sourced 0 Test Files.
  tclsh: Error detected by libpthread: Destroying condition variable in use.
  Detected by file "/home/builds/ab/netbsd-4/src/lib/libpthread/pthread_cond.c", line 93, function "pthread_cond_destroy".
  See pthread(3) for information.
  [1]   Abort trap (core dumped) TCL_LIBRARY=$(.....
  *** Error code 134

  Stop.
  make: stopped in /home/emiliano/tcl_sources/thread
  emiliano@maq033:~/tcl_sources/thread$

  The error is also shown using Tcl 8.4.15 with Thread 2.6.5 


tkt_uuid: 1835061fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.5b2
resolution: Fixed
title: Fail to build and test thread on Win32/MSVC
comment:
  Problems in the makefile.vc and test files prevent the thread package from being successfully built on Win32 using MSVC6 or MSVC8.

  (1) The link flag -nodefaultlib:msvcrt has been added in the case of non-static builds (which must link against MSVCRT).  This was probably added in error because Thread failed to link against a Tcl DLL which was compiled with different library flags (-MT instead of -MD).  This flag must be removed.

  (2) tests/all.tcl doesn't correctly load the Thread DLL (specified via -loadfile by the makefile.vc), so tests can't run at all.

  (3) tests/thread.test attempts to resolve $::tcl_PatchLevel on non-unix platforms (note capatalisation error: should be $::tcl_patchLevel).

  The attached patch fixes all these errors and bumps the package version to 2.6.6 (in configure.in and pkg.vc).  The maintainer will need to reconfigure.


tkt_uuid: 1851243fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Fixed
title: typo of tpool's man
comment:
  I found a little typo of manual of tpool.
  maxthreads and minthreads option is now 
  maxworkers and minworkers.


tkt_uuid: 1860425fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 9 Immediate
foundin: obsolete: 8.5.0
resolution: Fixed
title: core dump on FreeBSD, thread::create
comment:
  cvs checkout from 2007-12-22
  thread enabled build.
  FreeBSD 6.2

  %package require Thread
  2.6.5
  %thread::create {}
  tclsh in free(): error: junk pointer, too high to make sense



  This problem doesn't occur on 8.5a7 or 8.5b3 built the same way.


tkt_uuid: 1934666fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 7 High
foundin: obsolete: 8.5.1
resolution: Works For Me
title: Core dump when using 'clock format ...' in a thread
comment:
  OS = HP-UX 11 :
  I get a core dump when using any form of 'clock format ...'.

  Linux :
  I lost my KDE 'control bar' when running the script.


tkt_uuid: 1965721fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 8
foundin: obsolete: 8.5.2
resolution: None
title: memory corruption in thread pool ?
comment:
  I have written a tclscript that uses the packages listed below. After between a few hours and up to a week (approximately) it crashes with "alloc: invalid block" error. I compiled tcl and packages with symbols, trace follows below.

  In mainthread I am using:
  tcl: 8.5.2
  Thread: 2.6.5
  tls: 1.6
  udp: 1.0.9

  In threadpool threads I am using:
  tcl: 8.5.2
  Thread: 2.6.5
  mysqltcl: 3.05

  TpoolWorker() is trying to Tcl_Free() a (TpoolResult *rPtr) that 
  (a) when cast as a (char *) contains "replacedThisPrivateInfo 26 360969"
  (b) is different from the clientData it received
  (c) is not recognised as having been Tcl_Alloc'ed
  This hints at mem corruption?

  (gdb) bt 40
  #0  0xb7f70410 in ?? ()
  #1  0xad79c19c in ?? ()
  #2  0x00000006 in ?? ()
  #3  0x00003117 in ?? ()
  #4  0xb7cfd811 in raise () from /lib/tls/i686/cmov/libc.so.6
  #5  0xb7cfefb9 in abort () from /lib/tls/i686/cmov/libc.so.6
  #6  0xb7f0d4d6 in Tcl_PanicVA (format=0xb7f60fc4 "alloc: invalid block: %p: %x %x", argList=0xad79c384 "\033\226í·¸Ãy­Y¢ò·\bø\212\t") at /root/tcl8.5.2/unix/../generic/tclPanic.c:103
  #7  0xb7f0d506 in Tcl_Panic (format=0xb7f60fc4 "alloc: invalid block: %p: %x %x") at /root/tcl8.5.2/unix/../generic/tclPanic.c:132
  #8  0xb7f2ab35 in Ptr2Block (ptr=0x98af808 "replacedThisPrivateInfo 26 360969") at /root/tcl8.5.2/unix/../generic/tclThreadAlloc.c:735
  #9  0xb7f2a259 in TclpFree (ptr=0x98af808 "replacedThisPrivateInfo 26 360969") at /root/tcl8.5.2/unix/../generic/tclThreadAlloc.c:376
  #10 0xb7e7499d in Tcl_Free (ptr=0x98af808 "replacedThisPrivateInfo 26 360969") at /root/tcl8.5.2/unix/../generic/tclCkalloc.c:1182
  #11 0xb736e8cb in TpoolWorker (clientData=0xbfb7c31c) at ../generic/threadPoolCmd.c:1108
  #12 0xb7ec13cb in NewThreadProc (clientData=0x8223d80) at /root/tcl8.5.2/unix/../generic/tclEvent.c:1386
  #13 0xb7e30240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
  #14 0xb7da049e in clone () from /lib/tls/i686/cmov/libc.so.6

  The "replacedThisPrivateInfo" is private information that I've stripped out, it's a 41 characters long word.

  The string is read from a tls channel inside a fileevent. From there it's passed to a proc using this command: 
  catch {$command $sock $id [lrange $data 2 end]} error

  the proc looks like this:
  proc SIZES { sock id line } {
  if { [llength [split [join $line]]] == 3 } {
  foreach { dir files bytes } [split [join $line]] { }
  tpool::post -nowait $::pool "SIZES $sock $dir $files $bytes"
  log SIZES $dir $files $bytes ($::sockets($sock,user))
  } else {
  puts $sock [list $id SIZES usage [list {SIZES <dir> <files> <bytes>}]]
  }
  }

  In the threadpool the exact string is never found.

  The string is found again when the threadpool returns to the mainthread, where it sends it over a normal tcl (non tls) socket.

  The threadpool is started with the following command:
  set ::pool [tpool::create -minworkers $min -maxworkers $max -initcmd "source workers.tcl" -exitcmd {catch {mysql::close $::sql}}]

  Where both $min and $max is set to 20 so thread should only be created when script starts (had problems with threads not being created when needed).

  I'm afraid that I've been unable to make small simple script that has these results, the server also lasted much longer when it was in testing phase with just 10 or so clients on it, now it has about 120-150 concurrent clients.

  I use tpool::wait in a non standard way. In my process that read results, I wait for future job ids. I issue the tpool::wait command with a list of any incompleted jobs + future job ids up to 50 in total.


tkt_uuid: 1988779fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: Fixed
title: Tcl_SetStringObj called with shared object
comment:
  We're occasionally seeing panics with Thread.2.6.5 and Tcl.8.5.2:

     Tcl_SetStringObj called with shared object

  A typical stack trace is

  IOT/Abort trap in pthread_kill at 0xd005aaf4 ($t8)
  0xd005aaf4 (pthread_kill+0xa8) 80410014        lwz   r2,0x14(r1)
  (dbx) where
  pthread_kill(??, ??) at 0xd005aaf4
  _p_raise(??) at 0xd005a100
  raise.raise(??) at 0xd01e367c
  abort.abort() at 0xd01f2280
  Tcl_PanicVA() at 0xd4f14c78
  Tcl_Panic() at 0xd4f14cf4
  Tcl_SetStringObj() at 0xd4f3293c
  ThreadSend() at 0xd5ded484
  ThreadSendObjCmd() at 0xd5dea548
  TclEvalObjvInternal() at 0xd4f4b1c8
  (...)

  The implementation of ThreadSend in file thread2.6.5/generic/threadCmd.c contains the lines

      code = resultPtr->code;
      Tcl_SetStringObj(Tcl_GetObjResult(interp), resultPtr->result, -1);

  which seems suspicious. I see no compelling reason why Tcl_GetObjResult(interp) should be unshared at that point, so a plain

      Tcl_SetResult(interp, resultPtr->result, TCL_VOLATILE);

  should be used instead.

  Note: there's also a similar line in SvObjObjCmd in file 
  thread2.6.5/generic/threadSvCmd.c

   


tkt_uuid: 2005794fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.4.19
resolution: Fixed
title: tpool::create freezes when using minworkers
comment:
  When trying to use -minworkers when creating a threadpool, the tcl script just freezes up when the pool is to be created. This behaviour is irregular and the following code has been tested working on several platforms. On my previous linux installation, it worked 6/10 times, either it froze where indicated now, or it created the pool without trouble. That installation was a debian etch running tcl 8.4.

  The one I have this problem 10/10 times now, is a debian lenny. I got both tcl8.4.19 and tcl8.5.2 installed on it, and I get the exact same behaviour with both tcl versions. Thread was built from CVS to include the recent fix that closed bug 1965721.

  I'd be happy add any other information you might need and to try out any potential fix, as this probably will work on your end.

  Cheers
  rudenstam

  -----------------------------------------
   Code used to test this
  -----------------------------------------
  puts "Using tcl version: [info patchlevel]"
  puts "Loading threads version: [package require Thread]"

  set min 5
  puts "Creating the threadpool with: set pool \[tpool::create -minworkers $min\]"

  set pool [tpool::create -minworkers $min]

  puts "pool $pool created"

  -----------------------------------------
   Output of tclsh thread.tcl
  -----------------------------------------
  Using tcl version: 8.4.19
  Loading threads version: 2.6.5
  Creating the threadpool with: set pool [tpool::create -minworkers 5]

  -----------------------------------------
   Output of strace tclsh thread.tcl
  -----------------------------------------
  write(1, "Creating the threadpool with: se"..., 70Creating the threadpool with: set pool [tpool::create -minworkers 5]
  ) = 70
  mmap2(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6b22000
  mprotect(0xb6b22000, 4096, PROT_NONE)   = 0
  clone(child_stack=0xb73224c4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xb7322bd8, {entry_number:6, base_addr:0xb7322b90, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb7322bd8) = 14613
  futex(0x804c4c0, 0x81 /* FUTEX_??? */, 1) = 1
  futex(0x809a118, 0x81 /* FUTEX_??? */, 1) = 1
  futex(0x809a11c, 0x80 /* FUTEX_??? */, 1) = -1 EAGAIN (Resource temporarily unavailable)
  futex(0x804c4c0, 0x81 /* FUTEX_??? */, 1) = 0
  mmap2(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6321000
  mprotect(0xb6321000, 4096, PROT_NONE)   = 0
  clone(child_stack=0xb6b214c4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xb6b21bd8, {entry_number:6, base_addr:0xb6b21b90, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb6b21bd8) = 14614
  futex(0x804c4c0, 0x81 /* FUTEX_??? */, 1) = 1
  futex(0x809a118, 0x81 /* FUTEX_??? */, 1) = 1
  futex(0x809a11c, 0x80 /* FUTEX_??? */, 4) = -1 EAGAIN (Resource temporarily unavailable)
  futex(0x804c4c0, 0x81 /* FUTEX_??? */, 1) = 0
  mmap2(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb5b20000
  mprotect(0xb5b20000, 4096, PROT_NONE)   = 0
  clone(child_stack=0xb63204c4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xb6320bd8, {entry_number:6, base_addr:0xb6320b90, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb6320bd8) = 14615
  futex(0x804c4c0, 0x81 /* FUTEX_??? */, 1) = 1
  futex(0x809a118, 0x81 /* FUTEX_??? */, 1) = 1
  futex(0x809a11c, 0x80 /* FUTEX_??? */, 9) = -1 EAGAIN (Resource temporarily unavailable)
  futex(0x804c4c0, 0x81 /* FUTEX_??? */, 1) = 0
  mmap2(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb531f000
  mprotect(0xb531f000, 4096, PROT_NONE)   = 0
  clone(child_stack=0xb5b1f4c4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xb5b1fbd8, {entry_number:6, base_addr:0xb5b1fb90, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb5b1fbd8) = 14616
  futex(0x804c4c0, 0x81 /* FUTEX_??? */, 1) = 1
  futex(0x809a118, 0x81 /* FUTEX_??? */, 1) = 1
  futex(0x809a11c, 0x80 /* FUTEX_??? */, 16) = -1 EAGAIN (Resource temporarily unavailable)
  futex(0x804c4c0, 0x81 /* FUTEX_??? */, 1) = 1
  mmap2(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb4b1e000
  mprotect(0xb4b1e000, 4096, PROT_NONE)   = 0
  clone(child_stack=0xb531e4c4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xb531ebd8, {entry_number:6, base_addr:0xb531eb90, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb531ebd8) = 14617
  futex(0x804c4c0, 0x81 /* FUTEX_??? */, 1) = 1
  futex(0x809a118, 0x81 /* FUTEX_??? */, 1) = 1
  futex(0x809a11c, 0x80 /* FUTEX_??? */, 25) = -1 EAGAIN (Resource temporarily unavailable)
  futex(0x804c4c0, 0x81 /* FUTEX_??? */, 1) = 1
  write(1, "pool tpool0x8063ed0 created\r\n", 29pool tpool0x8063ed0 created
  ) = 29
  futex(0x809a11c, 0x84 /* FUTEX_??? */, 1) = 4
  futex(0x809b598, 0x81 /* FUTEX_??? */, 1) = 1
  futex(0x8088e64, 0x80 /* FUTEX_??? */, 1


tkt_uuid: 2050025fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: Threads extension fails to install in custom location
comment:
  Threads extensions does not install entirely in a custom location by using the configure option.

  Using --prefix= option of configure does not set the exec_prefix line in the makefile (it remains at /usr). This also, of course, results in an error if attempting to make install as a non-root user. Manually editing the makefile fixes this fairly trivially.

  Platform used was Mandriva Linux 2008.1


tkt_uuid: 219320ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.3b1
resolution: None
title: Tcl_Finalize doesn't clean-up running threads
comment:
  OriginalBugID: 3904 Bug
  Version: 8.3b1
  SubmitDate: '1999-12-20'
  LastModified: '2000-04-25'
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 3877
  OS: Windows 2000
  OSVersion: build 2128
  FixedDate: '2000-10-25'
  ClosedDate: '2000-10-25'


  Name:
  David Gravereaux

  CVS:
  I updated today

  CustomShell:
  tclAsync.c fixes in progress

  ReproducibleScript:
  D:\Projects\TclCVS\MainTclTrunk\win\Debug\>tcltest.exe
  % testthread create {
    load "d:/projects/ghe_cvs/ghe/ghe_dirwatch/debug/ghe_dirwatch.dll"
    GHE::startwatch c:/temp {gotcha [testthread id]}
    proc gotcha {id} {
      puts "c:/temp has been written to and yielded notifier thread $id"
    }
    testthread wait
  }
  1344
  % exit

  ObservedBehavior:
  The exit handler I made in the extension's Init with 
  Tcl_CreateThreadExitHandler wasn't called.


tkt_uuid: 219324ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 8
foundin: final: 8.2.3
resolution: Fixed
title: (tcltest) ThreadErrorProc not always called
comment:
  OriginalBugID: 3957 Bug
  Version: 8.2.3
  SubmitDate: '1999-12-29'
  LastModified: '2000-10-25'
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  OS: SunOS
  OSVersion: 5.6
  Machine: Sun Ultra
  FixedDate: '2000-10-25'
  ClosedDate: '2000-10-25'


  Name:

  Peter Silsbee


  Extensions:

  With tcltest, none. Separately, Expect, Tk, tix.


  CustomShell:

  N/A


  Comments:

  Patch is tentative. I'm totally unfamiliar with Tcl source, and have basically no idea what side effects it might cause!


  ReproducibleScript:

  Command line: tcltest script.tcl


  script.tcl:


  set errorthread [testthread create]


  set cmd "proc errorHandler \{id ei\} \{\

  puts \"This is my error procedure.\";\

  puts \"The thread is \$id\";\

  puts \"The errorInfo is <\$ei>\";\

  }"


  testthread send $errorthread $cmd

  testthread send $errorthread "testthread errorproc errorHandler"


  puts "About to commit an error in non-waiting thread"

  testthread create "set nonexistent"


  set thread2 [testthread create]


  puts "About to commit an error in the thread that is waiting"

  testthread send $thread2 "set nonexistent"


  after 2000


  puts "I survived to the end of the script"

  puts "The remaining threads are [testthread names]"


  ObservedBehavior:

  The procedure "errorHandler" is only called when an error occurs during "testthread create" script evaluation. When an error occurs during "testthread send" evaluation, ThreadErrorProc is never called.


  DesiredBehavior:

  ThreadErrorProc, hence errorHandler if registered, should be called on any thread error?


  Patch:

  *** generic/tclThreadTest.c.oldSat Oct 30 05:06:01 1999

  --- generic/tclThreadTest.c.newWed Dec 29 10:27:35 1999

  ***************

  *** 817,822 ****

  --- 817,830 ----

    if (code != TCL_OK) {

        errorCode = Tcl_GetVar(interp, "errorCode", TCL_GLOBAL_ONLY);

        errorInfo = Tcl_GetVar(interp, "errorInfo", TCL_GLOBAL_ONLY);

  +     ThreadErrorProc(interp);

  +     if (errorProcString != NULL) {

  +       /*

  +        * assume registered error handler can take care of things

  +        */

  +       code = TCL_OK;

  +       errorCode = errorInfo = NULL;

  +     }

    } else {

        errorCode = errorInfo = NULL;

    }


  PatchFiles:

  tclThreadTest.c


tkt_uuid: 2511408fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 9 Immediate
foundin: None
resolution: Fixed
title: mutex test errors
comment:
  Four tests raising errors in the HEAD
  of the Thread package:

  ==== thread-19.10 thread::mutex - destroy locked exclusive mutex FAILED
  ==== Contents of test case:

      set emutex [thread::mutex create]
      thread::mutex lock $emutex
      set x [catch {thread::mutex destroy $emutex} msg]
      thread::mutex unlock $emutex
      thread::mutex destroy $emutex
      list $x $msg

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: no such mutex "mid6"
      while executing
  "thread::mutex unlock $emutex"
      ("uplevel" body line 5)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== thread-19.10 FAILED



  ==== thread-19.11 thread::mutex - destroy locked recursive mutex FAILED
  ==== Contents of test case:

      set rmutex [thread::mutex create -recursive]
      thread::mutex lock $rmutex
      set x [catch {thread::mutex destroy $rmutex} msg]
      thread::mutex unlock $rmutex
      thread::mutex destroy $rmutex
      list $x $msg

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: no such mutex "rid7"
      while executing
  "thread::mutex unlock $rmutex"
      ("uplevel" body line 5)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== thread-19.11 FAILED



  ==== thread-20.6 thread::mutex - destroy readlocked mutex FAILED
  ==== Contents of test case:

      set rwmutex [thread::rwmutex create]
      thread::rwmutex rlock $rwmutex
      set x [catch {thread::rwmutex destroy $rwmutex} msg]
      thread::rwmutex unlock $rwmutex
      thread::rwmutex destroy $rwmutex
      list $x $msg

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: no such mutex "wid10"
      while executing
  "thread::rwmutex unlock $rwmutex"
      ("uplevel" body line 5)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== thread-20.6 FAILED



  ==== thread-20.7 thread::mutex - destroy writelocked mutex FAILED
  ==== Contents of test case:

      set rwmutex [thread::rwmutex create]
      thread::rwmutex wlock $rwmutex
      set x [catch {thread::rwmutex destroy $rwmutex} msg]
      thread::rwmutex unlock $rwmutex
      thread::rwmutex destroy $rwmutex
      list $x $msg

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: no such mutex "wid11"
      while executing
  "thread::rwmutex unlock $rwmutex"
      ("uplevel" body line 5)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== thread-20.7 FAILED


tkt_uuid: 2511424fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 9 Immediate
foundin: None
resolution: Fixed
title: condition variable error in thread-21.16
comment:
  ==== thread-21.16 thread::cond - delete waited variable FAILED
  ==== Contents of test case:

      ThreadReap
      set tid [thread::create]
      set emutex [thread::mutex create]
      set cond [thread::cond create]
      thread::send -async $tid [subst {
          thread::mutex lock $emutex
          thread::cond wait $cond $emutex 500
          thread::mutex unlock $emutex
      }]
      update
      after 10
      set c1 [catch {thread::cond destroy $cond} r1]
      thread::cond notify $cond
      after 1000
      set c2 [catch {thread::cond destroy $cond} r2]
      ThreadReap
      thread::mutex destroy $emutex
      list $c1 $c2 $r1 $r2

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: no such condition variable "cid30"
      while executing
  "thread::cond notify $cond"
      ("uplevel" body line 14)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== thread-21.16 FAILED


tkt_uuid: 2688159fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Invalid
title: Thread module fails to build against 8.6b1
comment:
  The thread module version 2.6.5 fails to build against Tcl 8.6b1.  I have seen this on OpenBSD 4.5 i386 w/ --enable-threads configure option, and also on Ubuntu 8.10 x86_64 w/ --enable-threads --enable-64bit configure options.  The same error message in both cases is:

  gcc -pipe -DPACKAGE_NAME=\"thread\" -DPACKAGE_TARNAME=\"thread\" -DPACKAGE_VERSION=\"2.6.5\" -DPACKAGE_STRING=\"thread\ 2.6.5\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DTCL_WIDE_INT_TYPE=long\ long -DUSE_TCL_STUBS=1   -I"/usr/local/include"    -O2 -Wall -Wno-implicit-int -fPIC -c `echo ./generic/threadSvCmd.c` -o threadSvCmd.o
  generic/threadSvCmd.c: In function `SvLockObjCmd':
  generic/threadSvCmd.c:2055: error: structure has no member named `errorLine'
  generic/threadSvCmd.c: In function `Sv_Init':
  generic/threadSvCmd.c:2156: warning: assignment discards qualifiers from pointer target type
  generic/threadSvCmd.c:2157: warning: assignment discards qualifiers from pointer target type
  generic/threadSvCmd.c:2158: warning: assignment discards qualifiers from pointer target type
  generic/threadSvCmd.c:2159: warning: assignment discards qualifiers from pointer target type
  generic/threadSvCmd.c:2160: warning: assignment discards qualifiers from pointer target type
  generic/threadSvCmd.c: At top level:
  generic/threadSvCmd.c:2236: warning: `SvFinalize' defined but not used
  gmake: *** [threadSvCmd.o] Error 1

  On the OpenBSD machine, this is the information in tcl_platform:

  tcl_platform(byteOrder)     = littleEndian
  tcl_platform(machine)       = i386
  tcl_platform(os)            = OpenBSD
  tcl_platform(osVersion)     = 4.5
  tcl_platform(pathSeparator) = :
  tcl_platform(platform)      = unix
  tcl_platform(pointerSize)   = 4
  tcl_platform(threaded)      = 1
  tcl_platform(user)          = taylor
  tcl_platform(wordSize)      = 4

  (The Linux platform information is not specified because I don't have access to it at the moment.)  I can provide additional information or try other things upon request.


tkt_uuid: 2777803fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Invalid
title: memory leak in ttrace
comment:
  there appears to be a memory leak when sourcing ttrace.tcl.

  namespace eval ttrace {
          ...
          variable mutex thread::mutex
          variable elock [$mutex create]
  ...}


  the mutex elock is never released when the thread & interpreter are recycled (i am using websh).

  i added a specific mutex destroy comand in the ttrace::cleanup procedure which solved the leak. but i don't think this is correct..

  i am using the latest thread from the cvs repository, with changes to replace Tcl_Alloc with ckalloc...


tkt_uuid: 2833864fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Fixed
title: tpool::create crashes on 64-bit Vista
comment:
  The tpool::create command fails to return on 64-bit Vista. The failing statement is in threadPoolCmd.c at line 288:
      sprintf(buf, "%s%p", TPOOL_HNDLPREFIX, tpoolPtr);
  The issue is the size of buf is too small.  Increasing its size from 16 to 32 solves the problem.


tkt_uuid: 2835615fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Accepted
title: Pool suspend/resume feature
comment:
  I think it would be nice to be able to suspend the processing of jobs by threads. That way one could turn off (suspend) job processing after a pool is created, load up the job queue with post, and then resume processing so the threads could process the job queue.  I have found on slower machines with only 2 cores that thread processing interfere with post operations. A possible solution would be to implement a tpool::pending command with a suspend/resume option that would return the list of pending jobs.


tkt_uuid: 2979572fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: None
title: compiler warnings threadSpCmd.c
comment:
  On the current HEAD:

  gcc -DPACKAGE_NAME=\"thread\" -DPACKAGE_TARNAME=\"thread\" -DPACKAGE_VERSION=\"2.6.5\" -DPACKAGE_STRING=\"thread\ 2.6.5\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long -DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1 -DHAVE_TYPE_OFF64_T=1 -DUSE_TCL_STUBS=1   -I"/home/dgp/cvs/tcl-only/generic"    -pipe -O2 -fomit-frame-pointer -Wall -fPIC  -c `echo /home/dgp/cvs/tcl-only/pkgs/thread2.6.5/generic/threadSpCmd.c` -o threadSpCmd.o
  /home/dgp/cvs/tcl-only/pkgs/thread2.6.5/generic/threadSpCmd.c: In function ‘ThreadRWMutexObjCmd’:
  /home/dgp/cvs/tcl-only/pkgs/thread2.6.5/generic/threadSpCmd.c:468: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/cvs/tcl-only/pkgs/thread2.6.5/generic/threadSpCmd.c: In function ‘SpMutexLock’:
  /home/dgp/cvs/tcl-only/pkgs/thread2.6.5/generic/threadSpCmd.c:1129: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/cvs/tcl-only/pkgs/thread2.6.5/generic/threadSpCmd.c:1132: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/cvs/tcl-only/pkgs/thread2.6.5/generic/threadSpCmd.c: In function ‘SpMutexUnlock’:
  /home/dgp/cvs/tcl-only/pkgs/thread2.6.5/generic/threadSpCmd.c:1161: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/cvs/tcl-only/pkgs/thread2.6.5/generic/threadSpCmd.c:1164: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/cvs/tcl-only/pkgs/thread2.6.5/generic/threadSpCmd.c: In function ‘SpMutexFinalize’:
  /home/dgp/cvs/tcl-only/pkgs/thread2.6.5/generic/threadSpCmd.c:1203: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/cvs/tcl-only/pkgs/thread2.6.5/generic/threadSpCmd.c:1206: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/cvs/tcl-only/pkgs/thread2.6.5/generic/threadSpCmd.c:1209: warning: dereferencing type-punned pointer will break strict-aliasing rules



  Would be good to silence these warnings before
  a release of Thread 2.6.6


tkt_uuid: 2979665fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Fixed
title: TEA version -> 3.7
comment:
  Thread's configure.in has

  TEA_INIT([3.6])

  asking for version 3.6 of TEA utilities.

  Current version of TEA is 3.7, and that's
  what a checkout of Thread delivers, leading
  to configure warnings.  Ought to reconcile this
  before releasing 2.6.6


tkt_uuid: 2980143fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 80. Thread Package
priority: 8
foundin: None
resolution: None
title: support return options
comment:
  The schemes in place to transport the
  values of -errorinfo and -errorcode
  produce by script evaluation in one thread
  over to a different thread have not been updated
  to accomodate the expanded return options
  dictionary that is part of Tcl 8.5+.

  Something I think should be corrected in a Thread 2.7.


tkt_uuid: 2980235fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Fixed
title: command pollution in interps w/o package require
comment:
  The pkgIndex.tcl file for the Thread and Ttrace
  packages creates the commands [::thread_load]
  and [::thread_source] inside every interp that
  happens to run [::tclPkgUnknown], whether or
  not that interp ever actually does a [package require]
  on Thread or Ttrace.  This is unwelcome pollution.
  Bad by any measure.  Doubly bad in the global namespace.

  This is very easy to fix with the use of the
  [::apply] command, so long as a dependence on
  Tcl 8.5 is permissible.

  If there is movement to better separate the two
  packages (see message on TCLCORE), then
  the index script may change enough as a result
  of that to make the issue go away.


tkt_uuid: 3006957fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Accepted
title: Script access to Tcl_CancelEval
comment:
  It would be useful to have a command

      thread::cancel ?-unwind? thread_id ?interp_path?

  that translates to the TIP #285 function implemented in Tcl 8.6

      int Tcl_CancelEval(Tcl_Interp *interp, ClientData clientData, int flags)

  and goes beyond "interp cancel" by allowing a script to cancel an interpreter in another thread.


tkt_uuid: 3007426fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Fixed
title: Build failure on AIX
comment:
  The AIX native cc, a strict c89 compiler, does not handle the trailing commas in enum declarations/definitions, and throws errors.
  Attaching a patch showing the problematic places, and a fix.


tkt_uuid: 3026061fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Accepted
title: threadCmd.c:Init() references an interp but not preserves it
comment:
  This bug is a member of "rare segfaults on exit" family. However I've found a way to reproduce it reliably:

  #!/usr/bin/wish8.6
  # The _wish_ interpreter is mandatory for reproducing the bug using this script: 
  # the example below depends on Tk_MainEx() being called.
  package req Thread
  package req Tk
  # Create thread pool
  set tph [tpool::create]
  # Post a long-running job
  tpool::post -nowait -detached $tph "after 5000; 
    [list thread::send -async [thread::id] {puts "foo bar, yep?"}];"
  # Make Tk/wish exit earlier than the job finishes
  after 3000 {destroy .}
  # And then it segfaults.

  What's going on?
  1. On initial `package require Thread', threadCmd.c:Init() is called for the main interpreter. Interps for other threads are created with threadCmd.c:NewThread(), only the main one is not _created_ but _registered_ with Init(). NewThread() takes care to Tcl_Preserve/Tcl_Release the interp when appropriate, but Init() doesn't. Pointer to the main interp is now stored in tsdPtr, but there is no Tcl_Preserve call to prevent its destruction, nor Tcl_CallWhenDeleted handler to wipe the pointer when the interp is destroyed. BAD.

  2. Thread pool is created and the job is posted, so a worker thread is created and NewThread is started in it. No problem here.

  3. Before the job finishes, main window is destroyed, and Tk_MainEx is going to exit.

  4. Tk_MainEx marks the main interp for deletion, then calls Tcl_Release on it, causing its actual deletion. From looking at Tk_MainEx I decided that it has the right to do what it does - that's why this bug is submitted against Thread package, not Tk. 

  4.1. At this point, tsdPtr of thread package has a dangling reference to a corpse of main interp. BAD.

  5. Then Tk_MainEx calls Tcl_Exit(0), which in turn invokes application exit handlers.

  6. ThreadPoolCmd.c:AppExitHandler() tries to destroy the thread pool gracefully. It causes a worker thread to exit and then waits for it, calling Tcl_DoOneEvent() repeatedly until there is no workers.

  7. But, _before_ the worker thread exits, it posts an event to the main thread, asking it to eval "puts..." within its main interp (that doesn't exist).

  8. threadCmd.c:ThreadEventProc() retrieves a dangling interp pointer from main thread's tsd.

  9. When it comes to Tcl_ResetResult(dead interp), wish segfaults.

  A possible solution, not nessesary the best one, is to add a couple of lines into threadCmd.c:Init():
   Tcl_Preserve(interp);
   Tcl_CreateThreadExitHandler(Tcl_Release, interp);

  Another possible solution is to assign NULL to tsdPtr->interp when interp is deleted (Tcl_CallWhenDeleted).


tkt_uuid: 3027815fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Accepted
title: Safe interpreters can use Thread to execute unsafe commands
comment:
  A safe interpreter can load all the commands of the Thread package.  This is a security issue, because it means that a safe interpreter can create a new thread and send commands to that thread's unsafe master interpreter:

  % ::safe::interpCreate iSafe
  iSafe
  % iSafe eval pwd
  invalid command name "pwd"
  % iSafe eval {
      package require Thread
      set tid [thread::create]
      ::thread::send $tid {pwd}
  }
  /home/user
  %

  At present the safe entry point Thread_SafeInit gives a safe interpreter access to all the commands of the Thread extension.  For security reasons, at least some of these commands should be removed.

  Perhaps safe interpreters should not be allowed any access to Thread commands.  I am not familiar with the whole of the Thread package, but it appears that the natural scope of a thread operation is the master interpreter of the thread.  If a safe interpreter needs limited access to Thread commands, it might be best provided by wrapper commands aliased into the safe slave from its unsafe master - not by loading the Thread package itself.

  I suggest removing the safe entry point Thread_SafeInit completely.


tkt_uuid: 3033206fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Fixed
title: lib/ttrace.tcl uses ::version as temporary variable
comment:
  The thread package includes lib/ttrace.tcl - loaded by [package require Ttrace] - uses $::version to temporarily store the result of [package require Thread] in a catch ("catch {package require Thread} version"). This global variable is unfortunately very likely to be used by applications (embedders mostly?) to hold their own version number. Eggdrop, for example, protects that variable as read-only with a write trace, causing [package require Ttrace] to fail because it can't write to that variable (and even if it could, it would overwrite Eggdrops version number and existing Tcl scripts for Eggdrop rely on it).
  I'd suggest changing it to anything else or a namespace variable.


tkt_uuid: 3056785fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 9 Immediate
foundin: None
resolution: Accepted
title: update to TEA 3.9 and Thread 2.6.7 release
comment:
  Attached is patch making changes to configure.in

  Apply and run autoconf to get the HEAD ready
  to produce Thread 2.6.7.


tkt_uuid: 3057497fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Duplicate
title: pkgIndex versions out of date on Win32
comment:
  When building under MSVC on WIN32 the pkgIndex.tcl file is created by the makefile.vc using constants in pkg.vc.  The PACKAGE_VERSION in pkg.vc is out of date, so Threads cannot be loaded into the interpreter.

  Patch:

  diff -r1.8 pkg.vc
  6c6
  < PACKAGE_VERSION       = "2.6.5"
  ---
  > PACKAGE_VERSION       = "2.6.6"


tkt_uuid: 3091176fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Fixed
title: Ttrace package out of sync with Thread package
comment:
  Ttrace package provides version 2.6.5 whilst Thread package aims for version 2.6.6.

  This makes ttrace to launch an error message when invoked.

  The tweak would go in line 65 of ttrace.tcl file.

  package provide Ttrace 2.6.6 


tkt_uuid: 3129844fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 8
foundin: obsolete: 8.5.9
resolution: Fixed
title: Thread hangs on specific exit sequence
comment:
  Running the following commands crashes tcl 8.5.9 in openSuse linux, windows XP/W7 doesn't crash.
  TCL compiled with MinGW/MinSYS.

  > package re Thread
  2.6.7
  > thread::names
  tid0xb71de8d0
  > thread::release [thread::id]
  > thread::names
  > update
  > exit


tkt_uuid: 3381371fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: None
title: possible memory leak?
comment:
  Using the latest ActiveState 8.6 and the Thread package on Ubuntu based distro, 32 bit, kernel 2.6.35-30
  I ran the following script 4 times:

       time {set ::t [thread::create]; thread::release $::t} 10000

  Here are the results from htop, one line for each invocation, first line is a state before the first run. 
  VIRT  RES  SHR
  15268 3296 1824
  32884 4632 1964
  33104 4936 1972
  33328 5160 1972
  33592 5384 1972

  There seems to be 100-300 byte leak for each invocation of the script. 


tkt_uuid: 3382401fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 80. Thread Package
priority: 7 High
foundin: None
resolution: Accepted
title: Thread pool leaks memory
comment:
  Using thread pool to do a computation in parallel with many thousand tasks, I noticed, that tpool leaks memory. The script attached demonstrates the loss both in ActiveTcl 8.5.10.1 on Windows/64 and in tcl8.6 HEAD on Mac OSX. My real computation ran for several hours on 6 cores and the leaked memory summed up to several hundred MB. I could not locate the leakage any further, first I thought the culprit was the tpool::wait command with the list result, but replacing it with a simple "after" in the test case has no influence. Also, tpool::release can not free the leaked memory.


tkt_uuid: 3382497fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: Out of Date
title: configure error in 2-6-branch
comment:
  Environment W7, MinGW; The branch 2-6-branch stops with an error in configure:

  checking if 64bit Sparc VIS support is requested... no
  checking if Windows/CE build is requested... no
  checking system version (for dynamic loading)... ./configure: line 10082: syntax error near unexpected token `('
  ./configure: line 10082: `    case `(ac_space=' '; set | grep ac_space) 2>&1` in'

  thx


tkt_uuid: 3383288fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 9 Immediate
foundin: obsolete: 8.6b2
resolution: Fixed
title: rules.vc missing support for MSVC10
comment:
  The rules.vc file has not been updated to support MSVC 2010.  Required patch is:

  Index: win/vc/rules.vc
  ===================================================================
  --- win/vc/rules.vc
  +++ win/vc/rules.vc
  @@ -187,11 +187,13 @@
   _VC_MANIFEST_EMBED_DLL=
   VCVER=0
   !if ![echo VCVERSION=_MSC_VER > vercl.x] \
       && ![cl -nologo -TC -P vercl.x $(ERRNULL)]
   !include vercl.i
  -!if $(VCVERSION) >= 1500
  +!if $(VCVERSION) >= 1600
  +VCVER=10
  +!elseif $(VCVERSION) >= 1500
   VCVER=9
   !elseif $(VCVERSION) >= 1400
   VCVER=8
   !elseif $(VCVERSION) >= 1300
   VCVER=7


tkt_uuid: 3407860fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: None
title: thread::exit flaws
comment:
  Perhaps there's no value fixing a command that's
  marked deprecated, but...

  [thread::exit] is documented to take no arguments,
  but that's not checked.  Any number of arguments
  are accepted and ignored without error.

  It would seem to be more valuable, both in utility
  and in parallel behavior with [::exit] for the command
  [thread::exit] to accept one optional argument, an
  integer "exit code" for the thread.

  Without such an argument [thread::exit] always
  declares the thread exit code to be 666, and
  [thread::join] returns that value as documented,
  when it is used.  But what value is that?  Returning
  a value that never changes?


tkt_uuid: 3407947fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 9 Immediate
foundin: None
resolution: Fixed
title: send to self appears to leak
comment:
  When [thread::send] sends to itself (the calling thread),
  a "short-circuit" in ThreadSend() calls on ThreadIdleProc()
  to do the work rather than ThreadEventProc().  ThreadIdleProc()
  never arranges to call ThreadFreeProc() to free the clientData.


tkt_uuid: 3411242fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 9 Immediate
foundin: None
resolution: Fixed
title: [thread::release -wait] crashes
comment:
  Implementation of [thread::release] doesn't properly
  support the command syntax of a single argument
  which is the option "-wait".  When it sees this, it
  still attempts to read the thread id from the second
  argument which is not there -- CRASH!


tkt_uuid: 3411244fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Fixed
title: [thread::release -wait [thread::id]] hangs
comment:
  The ThreadReserve() function handles a release
  of the current thread different from release of a
  different thread.  It does this assuming the current
  thread is identified by the magic id value "0".  

  However, if [thread::release -wait [thread::id]] is done,
  then the non-magic normal id of the current thread comes
  in, ThreadReserve() tries to treat it like any other thread,
  and ends up hanging waiting for itself.


tkt_uuid: 3439599fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 80. Thread Package
priority: 9 Immediate
foundin: obsolete: 8.6b2
resolution: None
title: thread::cancel not reporting error
comment:
  $ cat demo2.tcl
  package require Thread 2.7

  set ::bar "NO ERROR THROWN"
  proc ::foo {id info} {
      set ::bar "Thread $id stack:\n$info"
  }
  thread::errorproc ::foo

  set one [thread::create -joinable {while 1 {}}]
  thread::cancel $one
  thread::join $one
  puts stderr "SAVED ERROR: $::bar"


  $ make shell SCRIPT=demo2.tcl
  ...
  SAVED ERROR: NO ERROR THROWN


tkt_uuid: 3448556fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.5.11
resolution: Wont Fix
title: Segmentation fault on exit in tsv
comment:
  Sometimes my Tcl app crashes in between, but I'am somehow able to reproduce crashes (1 out of 5) when doing exit. I was able to trace this down with gdb.
  I looks like it is caused by the thread shared variables. Unfort. I havn't been able to create a simple tcl script to reproduce this problem.
  My Environment is WinXP, Tcl 8.5.11, Thread 2.7, Compiled with MinGW; Linux I didn't try.
  Thx


  (gdb) frame 0
  #0  0x6220a9e8 in Sp_RecursiveMutexLock (muxPtr=0x6c8)
      at ./generic/threadSpCmd.c:1536
  1536        if (*muxPtr == (Sp_RecursiveMutex_*)0) {
  (gdb) up
  #1  0x62206524 in LockArray (interp=0x17baf8e0, array=0x17e4eed0 "host",
      flags=0) at ./generic/threadSvCmd.c:728
  728         LOCK_BUCKET(bucketPtr); /* Note: no matching unlock below ! */
  (gdb)
  #2  0x62205d8e in Sv_GetContainer (interp=0x17baf8e0, objc=3,
      objv=0x17ba3c1c, retObj=0xd78f0b8, offset=0xd78f0bc, flags=0)
      at ./generic/threadSvCmd.c:338
  338             arrayPtr = LockArray(interp, array, flags);
  (gdb)
  #3  0x62207a7f in SvGetObjCmd (arg=0x0, interp=0x17baf8e0, objc=3,
      objv=0x17ba3c1c) at ./generic/threadSvCmd.c:1570
  1570        ret = Sv_GetContainer(interp, objc, objv, &svObj, &off, 0);
  (gdb)
  #4  0x64d92aa9 in TclEvalObjvInternal (interp=0x17baf8e0, objc=3,
      objv=0x17ba3c1c, command=0xffffffff <Address 0xffffffff out of bounds>,
      length=-1, flags=0) at ./../generic/tclBasic.c:3703
  3703            code = (*cmdPtr->objProc)(cmdPtr->objClientData, interp, objc, o
  bjv);
  (gdb)
  #5  0x64de4ba5 in TclExecuteByteCode (interp=0x17baf8e0, codePtr=0x17f17ed0)
      at ./../generic/tclExecute.c:2416
  2416                result = TclEvalObjvInternal(interp, objc, objv,
  (gdb)
  #6  0x64e3624a in TclObjInterpProcCore (interp=0x17baf8e0,
      procNameObj=0x17e64d10, skip=1, errorProc=0x64e3675d <MakeProcError>)
      at ./../generic/tclProc.c:1763
  1763            result = TclExecuteByteCode(interp, codePtr);
  (gdb)
  #7  0x64e361bd in TclObjInterpProc (clientData=0x17f129b8, interp=0x17baf8e0,
      objc=3, objv=0x17f15b60) at ./../generic/tclProc.c:1653
  1653            return TclObjInterpProcCore(interp, objv[0], 1, &MakeProcError);

  (gdb)
  #8  0x64d92aa9 in TclEvalObjvInternal (interp=0x17baf8e0, objc=3,
      objv=0x17f15b60, command=0x0, length=0, flags=131072)
      at ./../generic/tclBasic.c:3703
  3703            code = (*cmdPtr->objProc)(cmdPtr->objClientData, interp, objc, o
  bjv);
  (gdb)
  #9  0x64d92ffc in Tcl_EvalObjv (interp=0x17baf8e0, objc=3, objv=0x17f15b60,
      flags=131072) at ./../generic/tclBasic.c:3901
  3901        code = TclEvalObjvInternal(interp, objc, objv, NULL, 0, flags);
  (gdb)
  #10 0x64d94540 in TclEvalObjEx (interp=0x17baf8e0, objPtr=0x17bb6f38,
      flags=131072, invoker=0x0, word=0) at ./../generic/tclBasic.c:5129
  5129            result = Tcl_EvalObjv(interp, nelements, elements, flags);
  (gdb)
  #11 0x64d94414 in Tcl_EvalObjEx (interp=0x17baf8e0, objPtr=0x0, flags=131072)
      at ./../generic/tclBasic.c:5054
  5054        return TclEvalObjEx(interp, objPtr, flags, NULL, 0);
  (gdb)
  #12 0x64e48406 in AfterProc (clientData=0x17f258f0)
      at ./../generic/tclTimer.c:1145
  1145        result = Tcl_EvalObjEx(interp, afterPtr->commandPtr, TCL_EVAL_GLOBAL
  );
  (gdb)
  #13 0x64e47666 in TimerHandlerEventProc (evPtr=0xaaad7b8, flags=-3)
      at ./../generic/tclTimer.c:578
  578             (*timerHandlerPtr->proc)(timerHandlerPtr->clientData);
  (gdb)
  #14 0x64e251eb in Tcl_ServiceEvent (flags=-3) at ./../generic/tclNotify.c:675
  675             result = (*proc)(evPtr, flags);
  (gdb)
  #15 0x64e255c7 in Tcl_DoOneEvent (flags=-3) at ./../generic/tclNotify.c:978
  978             if (Tcl_ServiceEvent(flags)) {
  (gdb)
  #16 0x622044a5 in ThreadWait () at ./generic/threadCmd.c:2779
  2779            Tcl_DoOneEvent(TCL_ALL_EVENTS);


tkt_uuid: 3493120fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 80. Thread Package
priority: 7 High
foundin: obsolete: 8.5.11
resolution: None
title: Thread extension, memory leak after thread exit
comment:
  Version: 8.5.11 (original and current core-8-5-branch)
  Platform: Windows (linux not yet tested)

  After exiting of threads, they leave a memory leak. 
  Consequence of that: we cannot use techniques such as 'idletime' (to release some system resources, for example large tcl codes are no more used, etc, etc.).

  After run of following script I have lost 100MB of memory. In fact, nothing will be done here, except threads are created and exited.

  Test script:

  # for test purposes - to wait for threads exited :
  tsv::set testth count 0
  # this create once a thread pool, and generate jobs :
  proc test {} {
    # create a thread pool if not yet already exists :
    if {![llength [tpool::names]]} {
      tpool::create -minworkers 0 -maxworkers 5 -idletime 1 -initcmd {
        # + 1 thread
        tsv::set testth count [expr {[tsv::get testth count] + 1}]; puts [thread::id]init!!!!!
      } -exitcmd {
        # - 1 thread
        tsv::set testth count [expr {[tsv::get testth count] - 1}]; puts [thread::id]!!!!!exit
      }
    }
   # generate jobs until 5 threads are created :
    while {[tsv::get testth count] < 5} {
      tpool::post -detached -nowait [lindex [tpool::names] 0] {
        puts [thread::id]!!job; tsv::array unset testthcount [thread::id]
      }
      update
    }
  }
  # repeat test 100 times, in addition waiting for the 
  # threads to be finished each iteration :
  time {test; while {[tsv::get testth count]} {after 10};} 100


tkt_uuid: 3494470fffffffffffffffffffffffffffffffff
type: Bug
status: Pending
subsystem: 80. Thread Package
priority: 3 Low
foundin: obsolete: 8.5.10
resolution: Invalid
title: called Tcl_FindHashEntry on deleted table
comment:
  % puts $tcl_patchLevel
  8.5.10
  % parray tcl_platform
  tcl_platform(byteOrder)   = littleEndian
  tcl_platform(machine)     = x86_64
  tcl_platform(os)          = Linux
  tcl_platform(osVersion)   = 3.0.0-16-generic
  tcl_platform(platform)    = unix
  tcl_platform(pointerSize) = 8
  tcl_platform(threaded)    = 1
  tcl_platform(user)        = rtreleaven
  tcl_platform(wordSize)    = 8
  % 

  Problem Behavior
  The script below produces this output >90% but  <100% of the time.

  $ tclsh getHelp.tcl
  Does thread exist? no
  Does thread exist? no
  Does thread exist? no
  Does thread exist? no
  Does thread exist? no
  Does thread exist? no
  called Tcl_FindHashEntry on deleted table
  $ echo $?
  0

  Expected Behaviour
  The message "called Tcl_FindHashEntry on deleted table" should not be generated

  Concise Code Sample

  set truth(1) yes
  set truth(0) no
  package require Thread
  set id [ thread::id ]
  for { set i 0 } { $i < 6 } { incr i } {
  thread::create -preserved {
  while 1 {
  for { set i 0 } { $i < 9999999 } { incr i } {}
  update
  }
  }
  }
  after 1000
  foreach id [ thread::names ] {
  if { $id eq [ thread::id ] } { continue }
  thread::release -wait $id
  puts "Does thread exist? $truth([ thread::exists $id])"
  }


tkt_uuid: 3532972fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.5.11
resolution: None
title: Tcl Scripts results in "called Tcl_FindHashEntry on deleted"
comment:
  Tcl Version: 8.5.11
  OS Platform and Version: Windows 7 (64 bit) & Linux (32 bit)
  Thread Package: 2.6.6 (Linux) & 2.6.7 (Windows)

  Problem Behavior:
  - If script execution has finished the following output appears: called Tcl_FindHashEntry on deleted
  - Additionally, under Linux a core dump is created

  Expected Behavior:
  - A clean finalization of Tcl interpreter

  Tcl-Script:

  package require Thread

  set th1 [thread::create {puts worker_running ; thread::wait ; puts worker_stopped}]

  thread::send -async $th1 {puts script_started; after 5000; puts script_done} go

  puts "waiting for go..."

  vwait go

  if { [thread::exists $th1] } { 
      thread::release $th1
      puts worker_released
  }

  puts main_done


tkt_uuid: 3534440fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.5.11
resolution: Accepted
title: tpool::wait does not return pending jobs
comment:
  If the optional ?varname? is supplied to tpool::wait, it returns an empty string even if there are jobs pending.


tkt_uuid: 3534442fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.5.11
resolution: Accepted
title: tpool::create -idletime documentation incorrect
comment:
  The documentation for the -idletime option for tpool::create is incorrect. The last sentence, "Default value for this option is unspecified, hence, the Tcl interpreter of the worker thread will contain just the initial set of Tcl commands" is copied from the -initcmd option. The default value for -idletime is not specified.


tkt_uuid: 3534581fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.5.11
resolution: Accepted
title: tpool::post -nowait still waits
comment:
  The -nowait option to tpool::post appears to not work. It is supposed to post a job to the job queue immediately and return, however it seems to wait for a thread to become idle before returning.


tkt_uuid: 3543020fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 9 Immediate
foundin: obsolete: 8.6b3
resolution: Fixed
title: Thread extension not building with makefile. when in release
comment:
  The Threads package has a makefile.vc to build with Visual Studio in directory win/vc. When adding the Thread package to the pkgs directory for a 'batteries included' Tcl release, the makefile.vc file is moved from directory win/vc to directory win. This invalidates the ROOT variable used in the makefile.vc. It still has value ..\.. where after copying it should become ..


tkt_uuid: 3563391fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Accepted
title: Drop unused SpBucket fields
comment:
  The struct SpBucket declared in threadSpCmd.h has two
  fields, lockt and freeCt, that are never used anywhere.

  In the interest of simplification, I request we remove them.

  I would also like some comments added explaining the
  default value of 

  #define NUMSPBUCKETS 32

  and why someone customizing Thread source code might
  choose some other value.

  I think I'd be just as happy with a value of 1 myself, but that
  may be an opinion founded in ignorance.


tkt_uuid: 3567104fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.6b3
resolution: Fixed
title: pkgIndex.tcl bronken when building with Makefile.vc
comment:
  pkgIndex.tcl contains literal string "@TCL_VERSION@" when build with win/Makefile.vc.

  The patch is to add : @TCL_VERSION@ $(TCL_DOTVERSION) after line 440 of win/Makefile.vc


tkt_uuid: 3591021fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: current: 8.6.0
resolution: Fixed
title: compiler warning
comment:
  cc-1164 cc: WARNING File = /home/dgp/src/tcl8.6.0/pkgs/thread2.7.0/generic/threadSvCmd.c, Line = 1159
    Argument of type "ClientData" is incompatible with parameter of type
            "Tcl_CmdDeleteProc *".

        Tcl_CreateObjCommand(interp, buf, SvObjDispatchObjCmd, (int*)svObj, arg);
                                                                            ^


tkt_uuid: 405443ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 8
foundin: obsolete: 8.4a2
resolution: Works For Me
title: thread::send does not return
comment:
  After building tcl8.4a2 and thread2.1 on Windows 98, 
  Visual C++ V6 thread::send seems broken.  

  SYNOPSIS:
     package require Thread
     set child [thread::create]
     thread::send $child {set i 0}  #never returns

  I am under the impression that this command should
  return with a value of zero.  But control never comes
  back to the main thread.  The -async option works 
  correctly but I would like the results of child thread 
  commands.

  This worked under tcl8.3.2/thread2.1

  jim


tkt_uuid: 406058ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Bug in thread library
comment:
  working with Thread-2.1 under Windows-NT I found the  
  following bug. While executing

      for {set i 0} {$i < 1000} {incr i} { 
  set T [thread::create] 
  catch "thread::send $T thread::exit"
      }

  you can see in Task manager (of windows) that the  
  number of handles* grows up.

  * under processes in task manager choose columns in  
  View menu and mark number of handles.

  Greetings,
  Villalba


tkt_uuid: 416850ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 8
foundin: None
resolution: None
title: undocumented commands
comment:
  The thread extension is missing documentation for the 
  following commands:

  thread::mutex,
  thread::cond,
  thread::sv_get,
  thread::sv_exists,
  thread::sv_set,
  thread::sv_incr,
  thread::sv_append,
  thread::sv_lappend,
  thread::sv_array,
  thread::sv_unset


tkt_uuid: 418693ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Accepted
title: thread extension not resposible for this
comment:
  In the thread extension, ThreadWait inappropriatly 
  runs all events on the event loop directly.  I don't 
  think this is right.  When ThreadWait falls-out, the 
  stack should fall back to NewThread where 
  Tcl_DeleteInterp will happen.  Any *responsible* 
  extension who posts events to the event loop will be 
  notified here that the interp is going away and from 
  there they can remove offending events in the queue 
  before the notifier is torn-down.

  Just my 2 cents...


tkt_uuid: 421246ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Fixed
title: Problem with unix compilation in thread/
comment:
  Hi,

  The thread package doesn't compile under my system,
  Linux.

  Problem 1:  Can't configure - lacking config dir
  Fix:
  mkdir config
  automake -a
  before attempting configure.

  Problem 2: THREAD_VERSION* referenced, undeclared in
  ./generic/threadCmd.c
  Fix:
  diff -r ../thread/Makefile.in thread/Makefile.in
  126c126
  < CFLAGS_DEFAULT = @CFLAGS_DEFAULT@
  ---
  > CFLAGS_DEFAULT = @CFLAGS_DEFAULT@
  -DTHREAD_VERSION=\"${VERSION}\"
  -DTHREAD_VERSION_SUBSET83=\"${VERSION}\"

  Colin.


tkt_uuid: 439581ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: Works For Me
title: crash when application terminates
comment:
  Name: 
    Sangho Park

  Extensions: 
    Thread 2.1

  CustomShell: 

  Comments: 
    tcl 8.3.3 compiled on CC with threads enabled. 
  Solaris 2.5.1

  ObservedBehavior: 
    Below I include a thread script which causes a crash 
  when application terminate.  It crash 1~2 out of 20 
  executions. Error message is various : "Segment 
  Fault", "Tcl_Release couldn't find reference for 
  0xedfb8" "Bus Error". 

  ReproducibleScript: 

  -------- run.csh ------
  #!/bin/csh
  while ( 1 )
     main_thread.tcl
  end

  ---- main_thread.tcl ----
  #!/usr/local/bin/tclsh
  package require Thread

  set total_done 10
  set current 0

  proc returnProc {thread_result} {
  global total_done current
  incr current -1
  }

  for { set i 0 } { $i < $total_done} { incr i } {
      while { $current == 4 } {
  after 10 ; update
      }

      set childid1 [thread::create {source 
  child_thread.tcl; thread::wait}]
      incr current
      thread::send $childid1 "set b 100"
      thread::send -async $childid1 "run_child 
  [thread::id]"

  }

  while { [llength [thread::names]] > 1 } {
      after 10 ; update
  }

  ---- child_thread.tcl ----
  proc run_child { main_id } {
      thread::send $main_id "returnProc [thread::id]"
      thread::exit
  }


  DesiredBehavior: 
    It should not happen !!


tkt_uuid: 464340ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Fixed
title: thread::send might send to wrong interp
comment:
  Consider:

  set script {
     package require Thread
     set worker [thread::create {
       proc evaluate {cbThread script cbScript} {
         thread::send $cbThread\
           [list $cbScript [thread::id] [eval $script]]
       }
       thread::wait
     }]
     proc callback {thread value} {
       set ::continue {}
     }
     thread::send -async $worker \
         "evaluate [thread::id] list callback"
     vwait ::continue
     puts "$worker done"

  }

  set interp1 [interp create]
  $interp1 eval $script
  set interp2 [interp create]
  $interp2 eval $script

  The interp1 evaluation works fine. 
  The interp2 evaluation blocks indefinitely. 
  This is because the callback is executed in the
  wrong interpreter. The threading extension
  evaluates callbacks always in the main interpreter
  i.e. one which was active when the thread was started.

  Thanks for Jean-Luc Fontaine for pointing this out.


tkt_uuid: 486399ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 9 Immediate
foundin: obsolete: 8.4a3
resolution: Duplicate
title: Panic on exit before all threads returned
comment:
  Solaris 2.7, 2 CPU machine

  [belinda 14]--> gcc -v
  Reading specs from
  /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.3/specs
  gcc version 2.95.3 20010315 (release)

  Tcl 8.4a3, built thus:

  ./configure\
  --enable-threads\
  --enable-shared\
  --enable-gcc\
  --prefix=/opt/tcl8.4a3

  Thread package built thus:

  ./configure\
  --enable-gcc\
  --with-tcl=/opt/tcl8.4a3/lib\
  --enable-shared\
  --enable-threads\
  --prefix=/opt/tcl8.4a3

  The attached tar file contains three small scripts. If
  you run:

  tclsh8.4 boss.tcl

  You should be able to get it to do this:
  [belinda 66]--> tclsh8.4 boss.tcl
  task_done 6
  task_done 7
  task_done 8
  task_done 9
  task_done 10
  task_done 6
  task_done 7
  task_done 8
  task_done 9
  task_done 6
  10 exiting...
  BOSS: worker_exit 10
  8 exiting...
  7 exiting...
  BOSS: worker_exit 8
  BOSS: worker_exit 7
  9 exiting...
  BOSS: worker_exit 9
  6 exiting...
  BOSS: worker_exit 6
  BOSS: done...
  Tcl_Release couldn't find reference for 0x43938
  Abort (core dumped)

  My stack trace is:

  (gdb) where
  #0  0xff059968 in __sigprocmask () from
  /usr/lib/libthread.so.1
  #1  0xff04f1f0 in _resetsig () from
  /usr/lib/libthread.so.1
  #2  0xff04e93c in _sigon () from
  /usr/lib/libthread.so.1
  #3  0xff0517b4 in _thrp_kill () from
  /usr/lib/libthread.so.1
  #4  0xff0b9450 in abort () from /usr/lib/libc.so.1
  #5  0xff2ee028 in Tcl_PanicVA () from
  /opt/tcl8.4a3/lib/libtcl8.4.so
  #6  0xff2ee054 in Tcl_Panic () from
  /opt/tcl8.4a3/lib/libtcl8.4.so
  #7  0xff2f57f0 in Tcl_Release () from
  /opt/tcl8.4a3/lib/libtcl8.4.so
  #8  0xfe7c347c in ThreadEventProc ()
     from /opt/tcl8.4a3/lib/thread2.2/../libthread2.2.so
  #9  0xff2ec1e0 in Tcl_ServiceEvent () from
  /opt/tcl8.4a3/lib/libtcl8.4.so
  #10 0xff2ec538 in Tcl_DoOneEvent () from
  /opt/tcl8.4a3/lib/libtcl8.4.so
  #11 0xfe7c3148 in ThreadWait ()
     from /opt/tcl8.4a3/lib/thread2.2/../libthread2.2.so
  #12 0xfe7c1b28 in ThreadWaitObjCmd ()
     from /opt/tcl8.4a3/lib/thread2.2/../libthread2.2.so
  #13 0xff2eebec in EvalObjv () from
  /opt/tcl8.4a3/lib/libtcl8.4.so
  #14 0xff2ef230 in Tcl_EvalEx () from
  /opt/tcl8.4a3/lib/libtcl8.4.so
  #15 0xff2e33dc in Tcl_FSEvalFile () from
  /opt/tcl8.4a3/lib/libtcl8.4.so
  #16 0xff2b51ac in Tcl_SourceObjCmd () from
  /opt/tcl8.4a3/lib/libtcl8.4.so
  #17 0xff2eebec in EvalObjv () from
  /opt/tcl8.4a3/lib/libtcl8.4.so
  #18 0xff2ef230 in Tcl_EvalEx () from
  /opt/tcl8.4a3/lib/libtcl8.4.so
  #19 0xff2ef48c in Tcl_Eval () from
  /opt/tcl8.4a3/lib/libtcl8.4.so
  #20 0xfe7c2238 in NewThread ()
     from /opt/tcl8.4a3/lib/thread2.2/../libthread2.2.so


tkt_uuid: 487213ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Fixed
title: Thread does not build with Tcl 8.3
comment:
  The current HEAD revision of the Thread
  package doesn't configure, make, and
  make install cleanly on Linux(/Alpha)
  against Tcl 8.3.  Notably there's a
  missing substitution in pkgIndex.tcl,
  and a header file rename that hadn't
  been reflected in Makefile.in.

  Here's a patch, that restores
  installability, though not correct
  functioning.  (see next bug report)

  Hmmm.... looking at the patch, I see
  a dilemma over what version of
  autoconf to use.  Apparently the current
  HEAD was built with 2.52, but that appears
  to have cause configure failure (looking
  for a non-exitent config/config.sub file?)
  on Linux.  After adding the 

  AC_SUBST(THREAD_VERSION_SUBSET83)

  to configure.in, I just regen'd using
  autoconf 2.13, just cause that's what I have
  installed.  If this choice matters, we ought
  to come to an agreement on it.


tkt_uuid: 487214ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Fixed
title: missing ThreadKill() on unix
comment:
  After restoring ability to build and install Thread
  (see Bug 487213), I try a test:

  $ make test
  /usr/local/lib/../bin/tclsh8.3 ./tests/thread.test
  couldn't load file
  "/usr/local/lib/thread2.3/../libthread2.3.so":
  /usr/local/lib/thread2.3/../libthread2.3.so: undefined
  symbol: ThreadKill
      while executing
  "load /usr/local/lib/thread2.3/../libthread2.3.so"
      ("package ifneeded" script)
      invoked from within
  "package require Thread 2.0"
      (file "./tests/thread.test" line 18)
  make: *** [test] Error 1

  Sure enough, ThreadKillObjCmd() in generic/threadCmd.c
  calls ThreadKill() that is only implemented in
  win/threadWin.c.  The unix implementation is missing.


tkt_uuid: 503446ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 7 High
foundin: None
resolution: Duplicate
title: Thread: Installation of headers fails
comment:
  The thread package tries to install the 
  header "thread/generic/thread.h", which does not 
  exist. The correct file is "thread/generic/tclThread.h"

  Enclosed a patch to correct this.


tkt_uuid: 503451ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 8
foundin: None
resolution: Duplicate
title: Thread: Unknown "ThreadKill" function
comment:
  The command "thread::kill" (ThreadKillObjCmd) uses a 
  function "ThreadKill" which was unknown when I tried 
  to compile the package for Linux (linker bailed out). 
  I suspect that this function is a Win*-specific API. 
  Hence my initial assignment of this report to David.

  If my suspicion is confirmed we will need a TIP to 
  extend the public API of Tcl with a 
  generic "Tcl_ThreadKill" function analogous 
  to "Tcl_ThreadExit", albeit with a different signature.

  The nearest POSIX command to perform the same 
  operation is "pthread_kill" which sends a signal to a 
  specific thread. But I don't know if Tcl (or Linux) 
  knows how to deal with such.

  I do not know if there is something equivalent on the 
  Mac.


tkt_uuid: 560387ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.3
resolution: None
title: Package version incorrect
comment:
  The Thread 2.2 version reports version 2.1.1 when
  loaded. Among other things, this makes it impossible to
  confirm the correct Thread version (via package provide
  Thread).

  I believe the configure.in needs changing.


tkt_uuid: 577014ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 80. Thread Package
priority: 3 Low
foundin: None
resolution: Remind
title: documentation; wait on thread exits
comment:
  1. When will the documentation for the "Thread package 
  2.2" be available?
  2. When will it be possible to wait for the end of several 
  threads like the shell command "wait" does it for 
  background processes? (See "man wait")


tkt_uuid: 584123ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 80. Thread Package
priority: 9 Immediate
foundin: None
resolution: None
title: Patch to fully stub enable Thread packag
comment:
  Here is a patch that gets rids of the only
  undefined symbol in the Thread package.
  This is important since the undefined symbol
  makes it *very* difficult to load the Thread
  package into another executable that has
  also loaded Tcl dynamically.

  I ran into this problem while testing out
  Tcl Blend. The error message I was seeing
  looked like this:

  Exception in thread "main" tcl.lang.TclException:
  couldn't load file
  "/share/tcljava/build/thread/libthread2.4g.so":
  /share/tcljava/build/thread/libthread2.4g.so: undefined
  symbol: tclEmptyStringRep


  After much poking around and reading of man
  pages for dlopen, I found the problem. The
  Thread package must be self contained in
  order to work correctly. The package already
  takes care of this with a little hack for
  Windows. Thing is, this same hack is also
  needed under Linux. My patch makes that
  change. I am also going to include a testing
  program that I created to test shared lib
  loading using dlopen.


tkt_uuid: 595776ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.4b2
resolution: None
title: thread::send manpage innacurate
comment:
  diff -u -r1.6 thread.n
  --- doc/man/thread.n    22 Jul 2002 19:44:36 -0000      1.6
  +++ doc/man/thread.n    15 Aug 2002 22:58:28 -0000
  @@ -262,7 +262,7 @@
   \&\fBthread::exit\fP
   \&\fBthread::names\fP
   \&\fBthread::exists\fP
  -\&\fBthread::send\fP \fIid\fR ?\fI-async\fR?
  \fIscript\fR ?\fIvarname\fR?
  +\&\fBthread::send\fP ?\fI-async\fR? \fIid\fR
  \fIscript\fR ?\fIvarname\fR?
   \&\fBthread::wait\fP
   \&\fBthread::join\fP \fIid\fR
   \&\fBthread::configure\fP \fIid\fR ?\fIoption\fR?
  ?\fIvalue\fR\fI? ?\fR\fIoption value\fR\fI?...\fR

  Fixes the man page to reflect:

    /*
       * Syntax: thread::send ?-async? threadId script
  ?varName?
       */

  in the source code.


tkt_uuid: 599290ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: None
title: potential segfault in NewThread()
comment:
  In NewThread() (threadCmd.c):
    line 1476 calls Tcl_Release on tsdPtr->interp
    line 1498 uses tsdPtr->interp

  But tsdPtr->interp could point to free memory after
  releasing it.


tkt_uuid: 612513ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: None
title: Detect deadlocks with TCL
comment:
  I've read under "http://java.sun.com/j2se/1.4.1/changes.html#vm" about a utility that can detect deadlocks 
  with the programming language "Java". (Example listing: 
  http://java.sun.com/j2se/1.4.1/sample-output.html)

  Can a similar tool be offered for the programming language "TCL"?


tkt_uuid: 620154ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: None
title: Thread termination with TCL
comment:
  The documantion (http://cvs.sourceforge.net/cgi-
  bin/viewcvs.cgi/*checkout*/tcl/thread/doc/html/thread.html) has 
  got some warnings about the functions "thread::exit" and 
  "thread::unwind".
  Should some advices from the programming 
  language "Java" 
  (http://java.sun.com/j2se/1.4.1/docs/guide/misc/threadPrimitiveDeprecation.html) 
  be added to the descriptions?


tkt_uuid: 634845ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Fixed
title: thread::sync crashes on errors
comment:
  I'm using my own tclkit with --enable-threads, built on
  MinGW on Windows. Thread package is compiled static.

  Tcl crashes, when I do the following:

  set id [threac::create]
  thread::send -async $id {expr 1+1a} somevar

  It works when I send it without -async flag (I get an
  error).

  Versions:
  Windows 2000 Pro SP1
  Tcl/Tk: 8.4.1, from CVS - 2002-10-29
  Thread extension: 2.4
  $ gcc --version
  2.95.3-6


tkt_uuid: 659131ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 80. Thread Package
priority: 6
foundin: None
resolution: None
title: development targets: Complete pthreads?
comment:
  I want to continue our communication 
  (https://sourceforge.net/tracker/?group_id=10894&atid=360894&func=detail&aid=577014) 
  because the "Thread package 
  2.5" is available. The package has 
  been improved in severall ways.

  1. It seems that some things 
  that are offered by the pthreads library can still be done in the 
  future.
  - add missing lock types 
  (http://www.humanfactor.com/pthreads/pthread-code-
  snippets.html)

  2. more "convenience" functions for thread 
  shared variables
  "string", "regexp" or "keyed list" from the TclX 
  extension for example

  3. Will a thread that was not preserved 
  ("thread::create" without option "-preserved") exit 
  immediately?

  4. A sub function "names" is available for some 
  commands. I think that it would be needed for "thread::mutex" and 
  "thread::cond", too.

  5. When will it be possible to query the 
  mutexes and condition variables by which threads they are 
  used?

  6. The description for "thread::vwait" is missing. 
  (http://cvs.sourceforge.net/cgi-
  bin/viewcvs.cgi/*checkout*/tcl/thread/doc/html/thread.html)

  7. 
  The function "tsv::lock" is available. How do you think about a similar 
  function "thread::lock"?


tkt_uuid: 672050ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: None
title: function interface design and namespaces
comment:
  The programming interface for the thread package consists of 
  several functions that are grouped into a few namespaces. A lot of 
  functions have got a parameter/argument that specifies a 
  subcommand at the first position.

  How do you think about the 
  following suggestion?
  I would like to try an interface design like 
  that:
  Examples...
  1. thread::mutex lock 
      instead of
      
  thread::mutex::lock 

  2. thread::cond::create
      instead 
  of
      thread::cond create

  3. tsv::array::names
      instead 
  of
      tsv::array names

  Does the increased use of 
  namespace functions make a valuable difference in speed and 
  maintenance?
  Is it a step nearer to an object oriented TCL class 
  library for thread programming?


tkt_uuid: 674367ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: None
title: call for a function that is not thread safe
comment:
  I describe an use case for the handling of unsafe functions calls with 
  the thread package.

  I must assume that an application 
  programming interface (like a graphics library or a music API) or even 
  a single function is not thread safe if this property is not described in the 
  documentation for that API.
  So I must ensure that all unsafe 
  functions are executed by a single thread at each time. I want to create a 
  thread for each function library that must be handled as it has not 
  implemented thread safety at startup/initialization time of my 
  application. I want to achieve that calls into different unsafe libraries 
  can be executed simultaneously.

  I can perform the call with the 
  function "thread::send" for a thread that has been created before. But I 
  think that I will need a special kind of mutual exclusion. I understand the 
  thread package's documentation in the way that a mutex that is created 
  by the command "thread::mutex create" belongs to the calling thread. 
  It may not be stored in a thread shared variable. Please correct me if I 
  make wrong assumptions here.

  I guess that the function 
  "thread::eval" does not all what I want and need here. It does not expect 
  a thread indentifier in its argument list.
  I need a mutex that is global to 
  the process scope 
  (http://citeseer.nj.nec.com/cs?cs=1&q=synchronization+and+global+and+mutex&submit=Documents&co=Expected+Citations&cm=50&cf=Any&ao=Expected+Citations&am=20&af=Any
  ) 
  to perform a protected and synchronous call of a code piece that 
  should be executed by an other thread.
  I would like to suggest new 
  functions like the following.

  1. thread::mutex::create 
  global
           or
     thread::mutex -global create

  2. 
  thread::safecall id global_mutex script ?varname?


  How 
  do you think about this suggestion?
  Does this use case lead to add 
  more synchronization primitives to the thread package?


tkt_uuid: 674514ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 80. Thread Package
priority: 1 Zero
foundin: None
resolution: Accepted
title: Is Tcllib thread safe? - code analysis, flaw detection
comment:
  Do you know which functions of the Tcl Standard Library can be used 
  safely (no extra synchronization needed) with Tcl threads?
  When 
  will the information be added to the documentation 
  (http://tcllib.sourceforge.net/doc/index.html)whether a function in 
  this application programming interface is thread-safe or 
  asynchronous-safe or not?


tkt_uuid: 745976ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: None
title: Thread Extension missing 2.5.2 CVS tag
comment:
  The Tcl Thread Extension version 2.5.2 tarball was
  released 2003-04-29, but there appears to be no tag for
  2.5.2 in CVS.  Very bad.  Please fix.


tkt_uuid: 746352ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: None
title: warnings: operator== and not all paths return a value
comment:
  Thread 2.5.2
  modified function ListRemoveInner (threadCmd.c)
      } else if (tsdPtr == threadList) {
          threadList = NULL;   // was a == 
      }

  modified function Sp_Init (threadSpCmd.c)
    added return 0 because function is int


tkt_uuid: 762398ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: None
title: support thread priority (Windows only)
comment:
  I patched the threadCmd.c (of thread 2.5.2 package) so 
  you can change the thread priority in windows 
  environments.

  Everything that is modified is enclosed in an #ifdef 
  _USE_THREADPRIO/endif compiler statement.

  I don't know wether unix supports thread priorities.
  Thread priorities are 
  "normal", "above", "below", "high", "low", "idle", "unknown" 

  where unknown indicates an error.

  ***
  thread::configure ThreadId -priority 

  returns one of the above names. If none of them does 
  fit (should not happen) the int value is returned.

  If the thread doesn't have priority an empty string is 
  returned.

  ***
  thread::configure ThreadId -priority NewThreadPriority

  changes the thread priority
  Note: at the moment no error is returned on a failure

  ***
  maybe someone decides to integrate this in standard 
  thread library.

  Have fun with it!

  Harald


tkt_uuid: 838831ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: None
title: Add some tsv functions
comment:
  I would like to use the function "http://tcl.tk/man/tcl8.4/TclCmd/lset.htm" with thread shared variables.
  Do you know other functions that should or will be added later with TCL 8.5?


tkt_uuid: 884549ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 7 High
foundin: final: 8.3.5
resolution: None
title: Segmentation fault returning value in Thread for Thread 2.5
comment:
  I wrote a simple "exec" function that runs the
  specified program in another thread, splits out the
  stdout and
  stderr output and returns asynchronously.
  (I attached the script and traceback from the core dump
  at the end of this message.)

  I started off using Tcl 8.3.5/Thread 2.5 (2.1.5). It
  seems that if the  script running in the
  other thread returns a value using "return $result", I
  get a core dump. But, if I return the
  value using "set result", it doesn't core dump.

  If I use Tcl 8.4.5/Thread 2.5.2, the script throws an
  error condition if I use
  "return $result", but not if I use "set result". It
  should not be throwing
  an error condition. (It doesn't matter whether the
  print.tcl prints to
  stderr, it happens when only stdout  is printed as well.)

  Thanks,

  Rob



  test.tcl
  #!/bin/csh -f

  # comment out next line \
  exec tclsh8.3 $9 $argv:q
  #exec tclsh8.4 $9 $argv:q

  package require Thread

  namespace eval DE {

         proc threadError { threadid errorInfo } {
                 global DE::threadError
                 set threadError 1
                 return $threadError
         }

         proc texec { args } {
                 global DE::thread DE::threadError
  errorInfo errorCode
                 global result

                 set DE::threadError 0

                 set thread [thread::create]
                 thread::errorproc DE::threadError

                 set script {
                         set result ""
                         set filename tmp_[pid]

                         set errorCheck 0
                         set errorCheck [ catch { eval
  exec $program 2> $filename } result ]

                         set lines ""
                         if { $errorCheck > 0 } {
                                 set FILE [open $filename r]
                                 set lines [read $FILE 
  [file size $filename]]
                                 close $FILE
                                 file delete $filename
                                 error "$lines"
                         } else {
                                 file delete $filename
                                 #set output
                         }
                         set result [list $result $lines
  $errorCheck]

                         #set result; # this works
                         return $result ; # this doesn't
                 }

                 thread::send -async $thread "set program
  \"$args\"; $script" result

                 vwait result

                 if { $DE::threadError != 0 } {
                         error "Error executing command
  $args:\n$result\n$errorInfo"
                 }

                 if { [string length [lindex $result 1]]
  != 0 } {
                         puts stderr [lindex $result 1]
                 }

                 return [lindex $result 0]
         }

  }

  if { 1 } {
         catch {
                  puts [DE::texec ./print.tcl]
         } output
         puts "$output"
  }

  --------------------  file print.tcl
  -----------------------------------------------------

  #!/bin/csh

  # comment \
  exec tclsh $9 $*

  puts stdout "message from stdout"
  puts stderr "message from stderr"
  #error "throw an error"

  -------------------------------------- Traceback
  -----------------------------------

  Type "show copying" to see the conditions.
  There is absolutely no warranty for GDB.  Type "show
  warranty" for details.
  This GDB was configured as "i386-redhat-linux"...
  Core was generated by `tclsh8.3 test.tcl'.
  Program terminated with signal 11, Segmentation fault.
  Reading symbols from
  /fltapps/opt/mdopt/3dopt/Linux-2/lib/libtcl8.3g.so...done.
  Loaded symbols for
  /fltapps/opt/mdopt/3dopt/Linux-2/lib/libtcl8.3g.so
  Reading symbols from /lib/libdl.so.2...done.
  Loaded symbols for /lib/libdl.so.2
  Reading symbols from /lib/libpthread.so.0...done.
  Loaded symbols for /lib/libpthread.so.0
  Reading symbols from /lib/libm.so.6...done.
  Loaded symbols for /lib/libm.so.6
  Reading symbols from /lib/libc.so.6...done.
  Loaded symbols for /lib/libc.so.6
  Reading symbols from /lib/ld-linux.so.2...done.
  Loaded symbols for /lib/ld-linux.so.2
  Reading symbols from
  /fltapps/opt/mdopt/3dopt/Linux-2/lib/thread2.5/libthread2.5g.so...done.
  Loaded symbols for
  /fltapps/opt/mdopt/3dopt/Linux-2/lib/thread2.5/libthread2.5g.so
  #0  0x40184e27 in strlen () from /lib/libc.so.6
  (gdb) where
  #0  0x40184e27 in strlen () from /lib/libc.so.6
  #1  0x4008ed9d in Tcl_NewStringObj (bytes=0x726f7272
  <Address 0x726f7272 out of bounds>, length=-1)
     at ../generic/tclStringObj.c:167
  #2  0x4009638d in Tcl_SetVar2 (interp=0x804cd50,
  part1=0x400cea27 "errorCode", part2=0x0,
     newValue=0x726f7272 <Address 0x726f7272 out of
  bounds>, flags=1) at ../generic/tclVar.c:1079
  #3  0x40096362 in Tcl_SetVar (interp=0x804cd50,
  varName=0x400cea27 "errorCode",
     newValue=0x726f7272 <Address 0x726f7272 out of
  bounds>, flags=1) at ../generic/tclVar.c:1026
  #4  0x400c39d2 in ThreadClbkSetVar (interp=0x804cd50,
  clientData=0x807d4b8) at generic/threadCmd.c:1379
  #5  0x400c5889 in ThreadEventProc (evPtr=0x80831a8,
  mask=-3) at generic/threadCmd.c:2626
  #6  0x4007eb62 in Tcl_ServiceEvent (flags=-3) at
  ../generic/tclNotify.c:607
  #7  0x4007ee52 in Tcl_DoOneEvent (flags=-3) at
  ../generic/tclNotify.c:846
  #8  0x400590db in Tcl_VwaitObjCmd (clientData=0x0,
  interp=0x804cd50, objc=2, objv=0x804f268)
     at ../generic/tclEvent.c:990
  #9  0x40059e7f in TclExecuteByteCode (interp=0x804cd50,
  codePtr=0x8073b68) at ../generic/tclExecute.c:877
  #10 0x40036cb7 in Tcl_EvalObjEx (interp=0x804cd50,
  objPtr=0x8071ce8, flags=0) at ../generic/tclBasic.c:2733
  #11 0x4008ab2e in TclObjInterpProc
  (clientData=0x8073e40, interp=0x804cd50, objc=2,
  objv=0x804f260)
     at ../generic/tclProc.c:1001
  #12 0x40059e7f in TclExecuteByteCode (interp=0x804cd50,
  codePtr=0x8073538) at ../generic/tclExecute.c:877
  #13 0x40036cb7 in Tcl_EvalObjEx (interp=0x804cd50,
  objPtr=0x80696e0, flags=0) at ../generic/tclBasic.c:2733
  #14 0x4003b74b in Tcl_CatchObjCmd (dummy=0x0,
  interp=0x804cd50, objc=3, objv=0x804f250)
     at ../generic/tclCmdAH.c:264
  #15 0x40059e7f in TclExecuteByteCode (interp=0x804cd50,
  codePtr=0x8073438) at ../generic/tclExecute.c:877
  #16 0x40036cb7 in Tcl_EvalObjEx (interp=0x804cd50,
  objPtr=0x8071e38, flags=0) at ../generic/tclBasic.c:2733
  #17 0x4003f20a in Tcl_IfObjCmd (dummy=0x0,
  interp=0x804cd50, objc=3, objv=0xbfffe770)
     at ../generic/tclCmdIL.c:240
  #18 0x4008189b in EvalObjv (interp=0x804cd50, objc=3,
  objv=0xbfffe770,
     command=0x805e030 "\nif { 1 } {\n\tcatch {\n\t\t
  puts [DE::texec ./print.tcl]\n\t} output\n\tputs
  \"$output\"\n}\n", length=81, flags=0) at
  ../generic/tclParse.c:932
  #19 0x40082162 in Tcl_EvalEx (interp=0x804cd50,
     script=0x805db38 "#!/bin/tcsh -f\n\n# comment out
  next line \\\nexec tclsh8.3 $9 $argv:q\n#exec tclsh8.4
  $9 $argv:q\n\npackage require Thread\n\nnamespace eval
  DE {\n\n\tproc threadError { threadid errorInfo }
  {\n\t\tglobal DE::threa"..., numBytes=1353, flags=0) at
  ../generic/tclParse.c:1393
  #20 0x40076206 in Tcl_EvalFile (interp=0x804cd50,
  fileName=0xbfffec1c "test.tcl")
     at ../generic/tclIOUtil.c:323
  #21 0x40079d81 in Tcl_Main (argc=1, argv=0xbfffede8,
  appInitProc=0x80486b6 <Tcl_AppInit>)
     at ../generic/tclMain.c:227
  #22 0x080486ac in main (argc=2, argv=0xbfffede4) at
  ../unix/tclAppInit.c:99
  #23 0x401221c4 in __libc_start_main () from /lib/libc.so.6
  (gdb)


tkt_uuid: 918137ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.4.6
resolution: Fixed
title: pkgIndex.tcl breaks Tcl 7
comment:
  If the Thread package gets installed
  in a directory that happens to be on
  the auto_path of a Tcl 7 interpreter,
  its index script (pkgIndex.tcl) causes
  errors in that interpreter.  This can
  be corrected by a rewrite of Thread's
  pkgIndex.tcl.in file to:

  # Tcl package index file, version 1.1

  if {![package vsatisfies [package provide Tcl] 8.3]}
  {return}
  if {[string equal 8.3 [package provide Tcl]]} {
      package ifneeded Thread @THREAD_VERSION_SUBSET83@ \
              [list load [file join $dir
  @thread_LIB_FILE@] Thread]
  } else {
      package ifneeded Thread @VERSION@ \
              [list load [file join $dir
  @thread_LIB_FILE@] Thread]
  }
  package ifneeded Ttrace @TTRACE_VERSION@ \
          [list source [file join $dir ttrace.tcl]]


  (Patch also attached.)

  See also http://wiki.tcl.tk/5900


tkt_uuid: 933975ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: None
resolution: Fixed
title: tpool::create -minworkers
comment:
  When using larger values for -minworkers tpool::create
  never returns and Ctrl-C is required.  On my platform,
  it seems to not like more than 12 worker threads. 
  Setting -maxworkers fixes it with some larger values
  but not others.

  Minimal sample code:

    package require Thread 2.6
    set ::threads [tpool::create -minworkers 16 -idletime
  120]
    puts "id $::threads"

  Both Tcl and Threads 2.6 were pulled from CVS
  lastnight, but I noticed the same problem with 2.5. 
  tpool.tcl works as expected.

  Fully updated Redhat/Fedora Core 1, dual Athlon 2100, 1
  gig of system memory.


tkt_uuid: 987512ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Wont Fix
title: mem-leak in thread::send -async
comment:
  hi, I hope, this is a bug and is not work as designed :=)

  this testscript confiscated over 9MByte Ram. the
  call thread::send -async send 385 Bytes to the thread and
  after 25000 calls, the thread use ~9300 KByte memory
  (offset) ! after I release the thread, the memory will
  not be freed. if I send the script without -async, all
  memory will be 
  freed.

  I have make the test with the current cvs snap-shot 
  changelog -> R1.2132, Wed Jul 7 22:05:56 2004
  on a linux 2.6.7 i386 & ppc system, with & without
  USE_THREAD_ALLOC in the CFLAG.

  before som days, i have posted a problem in the
  tcl-thread-list, i think, it is the same problem. 

  regards, joerg 

  set ::Thread {
    proc TestProc {args} {
      set x "xxxxxxxxxxxxxxxxxxxxxxxx"
      set x "xxxxxxxxxxxxxxxxxxxxxxxx"
      set x "xxxxxxxxxxxxxxxxxxxxxxxx"
      set x "xxxxxxxxxxxxxxxxxxxxxxxx"
      set x "xxxxxxxxxxxxxxxxxxxxxxxx"
      set x "xxxxxxxxxxxxxxxxxxxxxxxx"
      set x "xxxxxxxxxxxxxxxxxxxxxxxx"
      set x "xxxxxxxxxxxxxxxxxxxxxxxx"
      set x "xxxxxxxxxxxxxxxxxxxxxxxx"
      return 0
    }
    TestProc
  }

  set thid [thread::create "thread::wait"]
  for {set ni 0} {$ni < 25000} {incr ni} {thread::send
  -async $thid $::Thread}
  thread::send $thid -async "thread::release"

  vwait forever


tkt_uuid: 994229ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
foundin: obsolete: 8.4.6
resolution: Fixed
title: tsv::lock doesn't lock between threads
comment:
  A [tsv::lock <arrayName>] will not prevent two threads 
  from accessing the tsv array.

  % puts $tcl_version
  8.4
  % array get tcl_platform
  osVersion 7.3.0 byteOrder bigEndian threaded 1 machine 
  {Power Macintosh} platform unix os Darwin user ts
  anders wordSize 4
  % package require Thread
  2.5

  Testcase:

  package require Thread

  tsv::set global true 1
  tsv::set global false 0

  set a [thread::create]
  set b [thread::create]
  set ::finish 0

  thread::send $a [list set x [thread::id]]; # main thread 
  id
  thread::send -async $a {
      set ::finish 0
      puts "a: [thread::id]"
      tsv::lock global {
          puts "a: has global lock ([tsv::get global true])"
          tsv::set global true 2
          vwait ::finish
      }
      puts "a: released global lock"
      thread::send $::x {incr ::finish}
  }

  # kick thread a out of lock
  after 5000 {thread::send $a {incr ::finish}}

  after 1000 {
      thread::send -async $b {
          puts "b: [thread::id], waiting for global lock"
          tsv::lock global { puts "b: got global lock 
  ([tsv::get global true])" }
          puts "b: released global lock"
      }
  }

  vwait ::finish


  Output:

  a: 25173504
  a: has global lock (1)
  b: 25174528, waiting for global lock
  b: got global lock (2)
  b: released global lock
  a: released global lock


  You can see that b was able to obtain the lock and 
  access the tsv global array data while thread 'a' had the 
  lock.

  I saw one message in the forum about this also but the 
  person never got an answer there.   Any clues?  I 
  peeked at the code and didn't see an immediate problem 
  but I'm not familiar with that code at all.

  sanders012<at>earth.com


tkt_uuid: 3534607fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.5.11
resolution: Fixed
title: tpool::get sets errorInfo incorrectly
comment:
  When tpool::get is called on a job that exited with an error, the first line of errorInfo is set incorrectly (the text is doubled).


tkt_uuid: 4e30d60da7d105bd603350b74b6c99c3e28cb73e
type: Bug
status: Closed
subsystem: 80. Thread Package
priority: 5 Medium
severity: Minor
foundin: 2.7.0
private_contact: 54152f94cb1628c0c148b4b5708ace53216227b0
resolution: Duplicate
title: Error message is doubled in -errorinfo in rethrown exception using tpool::get
comment:
  Using tpool, exceptions thrown from jobs in worker threads appear to have the error message duplicated in the first line of the -errorinfo trace in the options dict.  For example the script:

  package require Thread 2.7.0

  set pool    [tpool::create -initcmd {
      proc t {} {
          throw {HELLO WORLD} "test res"
      }
  }]

  tpool::preserve $pool

  set job_id  [tpool::post $pool t]
  tpool::wait $pool $job_id
  catch {tpool::get $pool $job_id} res options
  puts [dict get $options -errorinfo]

  tpool::release $pool


  Produces the output:

  test restest res
      while executing
  "throw {HELLO WORLD} "test res""
      (procedure "t" line 2)
      invoked from within
  "t"
      invoked from within
  "tpool::get $pool $job_id"


  Tcl version: 8.6.1
  Platform: linux-glibc2.19-x86_64 (Ubuntu 14.04 64bit)


tkt_uuid: 41922d3bb7c43da1c6e0cf36c3b4b5ccbb89b564
type: Bug
status: Open
subsystem: 80. Thread Package
priority: 5 Medium
severity: Minor
foundin: current
private_contact: 36034badbf4fa68e1e6f55bc81729916152660a8
resolution: None
title: Please regenerate the docs.
comment:
  Newer versions of doctools make better docs, don't have bugs in nroff format.
  '.TH' should come before the macros in .n files.
  See Tcl ticket [426679ef7d].


