Ticket UUID: | bc4552d0bb8d4489b1d9675bbf7e0873d32bdb0c | |||
Title: | Tcl_SetServiceMode in nextEventMatchingMask can be removed | |||
Type: | Patch | Version: | trunk | |
Submitter: | anonymous | Created on: | 2014-01-23 14:08:43 | |
Subsystem: | 70. Event Loop | Assigned To: | dgp | |
Priority: | 5 Medium | Severity: | Minor | |
Status: | Closed | Last Modified: | 2014-10-31 19:29:55 | |
Resolution: | Postponed | Closed By: | dgp | |
Closed on: | 2014-10-31 19:29:55 | |||
Description: |
In the nextEventMatchingMask method in macosx/tkMacOSXNotify.c, in this section: @implementation TKApplication(TKNotify) - (NSEvent *) nextEventMatchingMask: (NSUInteger) mask untilDate: (NSDate *) expiration inMode: (NSString *) mode dequeue: (BOOL) deqFlag { ... int oldMode = Tcl_SetServiceMode(TCL_SERVICE_ALL); NSEvent *event = [[super nextEventMatchingMask:mask untilDate:expiration inMode:mode dequeue:deqFlag] retain]; Tcl_SetServiceMode(oldMode); ... } we first set the service mode using Tcl_SetServiceMode, then we call the nextEventMatchingMask method of the superclass, and then we restore the original service mode. The Tcl_SetServiceMode function (in generic/tclNotify.c) is the following: int Tcl_SetServiceMode(int mode) { int oldMode; ThreadSpecificData *tsdPtr = TCL_TSD_INIT(&dataKey); oldMode = tsdPtr->serviceMode; tsdPtr->serviceMode = mode; Tcl_ServiceModeHook(mode); return oldMode; } Now the superclass nextEventMatchingMask method simply gets the next available event, but does not invoke any Tcl/Tk code. So setting tsdPtr->serviceMode has no consequences. The Tcl_ServiceModeHook function (in macosx/tclMacOSXNotify.c) creates the runloop timer if it doesn’t already exist. But since we also call Tcl_SetServiceMode from Tk_MacOSXSetupTkNotifier during Tk initialization, the runloop timer already exist by the time we call nextEventMatchingMask. So I think the two calls to Tcl_SetServiceMode in the nextEventMatchingMask method can be removed. The patch does just that. This patch was made relative to this patch which I submitted previously: https://core.tcl.tk/tcl/tktview?name=883155fb98 However, these two patches can be applied independently of each other. | |||
User Comments: |
anonymous added on 2014-10-31 00:49:24:
I submitted this patch back in January, but since then I have been looking at the Tcl/Tk event loop code in much more detail, and it's clear to me that much more extensive changes are needed to solve the event loop issues. I would suggest to close this ticket for now, and wait for a comprehensive solution of the event loop (which may take a few more months). dgp added on 2014-10-30 13:20:05: I'll take a look at this. Not right away. kevin_walzer added on 2014-10-29 13:49:50: I see no point in incorporating a patch just for code cleanup. I would prefer that patches to the event loop address more substantive issues, i.e. its performance under Cocoa. kevin_walzer added on 2014-02-02 02:44:10: As with bug 883155fb98, this patch doesn't cause any apparent side effects, but what improvement it offers is not entirely clear to me. |
Attachments:
- tkMacOSXNotify.c.patch [download] added by anonymous on 2014-01-23 14:10:38. [details]