summaryrefslogtreecommitdiffstats
path: root/generic/tkEvent.c
diff options
context:
space:
mode:
authordgp <dgp@users.sourceforge.net>2005-09-28 18:31:57 (GMT)
committerdgp <dgp@users.sourceforge.net>2005-09-28 18:31:57 (GMT)
commit242ca27e8759537c7fe5c640c66084aee13fc51f (patch)
treebe807328b612492b3c2370bd43c69bb8a2a3d2aa /generic/tkEvent.c
parentcf7a15b4c3e49dc9076c2c8fb3e80f179928946d (diff)
downloadtk-242ca27e8759537c7fe5c640c66084aee13fc51f.zip
tk-242ca27e8759537c7fe5c640c66084aee13fc51f.tar.gz
tk-242ca27e8759537c7fe5c640c66084aee13fc51f.tar.bz2
* unix/tkUnixPort.h: Disabled inclusion of the private Tcl header
* win/tkWinPort.h: file tclInt.h. Tk ought to have a tiny and shrinking number of calls of private Tcl routines. Each Tk source file doing this should follow the convention in the macosx port and have its own #include "tclInt.h". * generic/tkEvent.c: Disabled calls to private Tcl routine TclInExit(). See comment in TkCreateExitHandler() for full rationale.
Diffstat (limited to 'generic/tkEvent.c')
-rw-r--r--generic/tkEvent.c26
1 files changed, 23 insertions, 3 deletions
diff --git a/generic/tkEvent.c b/generic/tkEvent.c
index fa81b65..ceffd0a 100644
--- a/generic/tkEvent.c
+++ b/generic/tkEvent.c
@@ -12,7 +12,7 @@
* See the file "license.terms" for information on usage and redistribution of
* this file, and for a DISCLAIMER OF ALL WARRANTIES.
*
- * RCS: @(#) $Id: tkEvent.c,v 1.29 2005/09/21 10:54:40 dkf Exp $
+ * RCS: @(#) $Id: tkEvent.c,v 1.30 2005/09/28 18:31:57 dgp Exp $
*/
#include "tkPort.h"
@@ -1880,7 +1880,26 @@ TkCreateExitHandler(
exitPtr->proc = proc;
exitPtr->clientData = clientData;
Tcl_MutexLock(&exitMutex);
- if (firstExitPtr == NULL && !TclInExit()) {
+
+ /*
+ * The call to TclInExit() is disabled here. That's a private
+ * Tcl routine, and calling it is causing some trouble with portability
+ * of building Tk. We should avoid private Tcl routines generally.
+ *
+ * In this case, the TclInExit() call is being used only to prevent
+ * a Tcl_CreateExitHandler() call when Tcl finalization is in progress.
+ * That's a situation that shouldn't happen anyway. Recent changes
+ * within Tcl_Finalize now cause a Tcl_Panic() to happen if exit
+ * handlers get added after exit handling is complete. By disabling
+ * the guard here, that panic will serve to help us find the buggy
+ * conditions and correct them.
+ *
+ * We can restore this guard if we find we must (hopefully getting
+ * public access to TclInExit() if we discover extensions really do
+ * need this), but during alpha development, this is a good time to
+ * dig in and find the root causes of finalization bugs.
+ */
+ if (firstExitPtr == NULL/* && !TclInExit()*/) {
Tcl_CreateExitHandler(TkFinalize, NULL);
}
exitPtr->nextPtr = firstExitPtr;
@@ -1958,7 +1977,8 @@ TkCreateThreadExitHandler(
exitPtr = (ExitHandler *) ckalloc(sizeof(ExitHandler));
exitPtr->proc = proc;
exitPtr->clientData = clientData;
- if (tsdPtr->firstExitPtr == NULL && !TclInExit()) {
+ /* See comments in TkCreateExitHandler */
+ if (tsdPtr->firstExitPtr == NULL/* && !TclInExit()*/) {
Tcl_CreateThreadExitHandler(TkFinalizeThread, NULL);
}
exitPtr->nextPtr = tsdPtr->firstExitPtr;