OriginalBugID: 3862 Bug
Version: 8.3b1
SubmitDate: '1999-12-13'
LastModified: '2000-04-04'
Severity: CRIT
Status: Closed
Submitter: techsupp
ChangedBy: hobbs
RelatedBugIDs: 4826 5791
OS: Windows 2000
FixedDate: '2000-10-25'
ClosedDate: '2000-04-04'
Name:
David Gravereaux
CVS:
I updated today
Comments:
You can contact me for more details regarding that extensions use of Tcl_AsyncMark/Tcl_QueueEvent. I tried adding a TSD structure to tclAsync.c, but I couldn't the system to work. Something isn't right with how the yielding is currently working. Never mind for the moment that Tcl_AsyncReady is process global rather than thread specific.
ReproducibleScript:
D:\Projects\TclCvs\MainTclTrunk\win\Release>tcltest.exe
% update
% testthread create {
load "d:/projects/ghe_cvs/ghe/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
}
1156
% testthread id
1176
% update
c:/temp has been written to and yielded notifier thread 1176
% update
c:/temp has been written to and yielded notifier thread 1176
c:/temp has been written to and yielded notifier thread 1176
c:/temp has been written to and yielded notifier thread 1176
% update
c:/temp has been written to and yielded notifier thread 1176
% update
c:/temp has been written to and yielded notifier thread 1176
c:/temp has been written to and yielded notifier thread 1176
c:/temp has been written to and yielded notifier thread 1176
%
ObservedBehavior:
Creating a new interp with testthread (threadID 1156 above) resulted in the EventProc of that extension to happen in the wrong thread (id 1176). This a problem. The thread that didn't create that interp is Eval'ing code in it!
DesiredBehavior:
The EventProc gets called in from the correct thread.
