[MACTCL] How to move forward with Tk-Cocoa event loop issues

[Kevin W. <kw...@co...>]

Hi all,

I just closed bug #3028676 
(https://sourceforge.net/tracker/index.php?func=detail&aid=3028676&group_id=12997&atid=112997). 
This is my reference bug for the Tk-Cocoa event loop issues, because 
Lars Hellström (the OP) did a lot of investigating to isolate the source 
of the problem, and Daniel Steffen (das, the author of the Tk-Cocoa 
port) added some very useful points about his design intent.

Let me quote from my comments there:

---
Adding an "update" command to the core procedure in the sample script
sidesteps the problem entirely.

I realize that this script was put together to assemble the core issue,
that is, incoming Tcl events overloading the Cocoa/Tk event loop and
causing it to lock up, but the fact is that careful management of the event
loop with occasional workarounds like "update" or "after" can avoid many of
the issues that are commonly reported.

I've spent a lot of time reading both das's code and the relevant docs (Tcl
and CoreFoundation), and given the complexity of the task, I've concluded
that the current implementation is good enough, albeit far from optimal.
das had previously committed a significant update to the notifier, see
https://sourceforge.net/mailarchive/message.php?msg_id=23324050, that
addressed truly showstopper issues with its performance. Now it is slow and
pone to occasional lockups, but in most cases these can be worked around.  I
seldom see any issues with the event loop in my own applications because I
work around the most common issues; it's been a long time since I've had a
user complaint about a lockup because of event loop issues.

It seems clear that the Tk/Cocoa event loop is slower, more fragile, and
more complex than the Carbon implementation; however, the ultimate
responsibility for this lies with Apple's decision to deprecate Carbon and
force Cocoa integration. Cocoa has many advantages, but it is not a natural
fit for Tk the way that Carbon, which operated at the same low level of
abstraction as Tk's C API, was.

Therefore, I've decided to close this bug, and will spend a bit of time
deciding how to document the limitations of Tk-Cocoa's event loop and best
practices for working around them.
---

At this point I don't think it's fruitful to try to improve the event 
loop integration. Frankly, given the enormity of the task, I think the 
work Daniel Steffen did single-handed on Tk-Cocoa is just amazing, and 
I'm grateful for his efforts. The event loop code is some of the 
gnarliest of the source tree, and based on bug reports, Daniel pushed it 
forward from showstopping slow/crashprone to Barely Good Enough. 
(That's not faint praise but rather high praise based on the difficulty 
of the task.) As I say in my comment above, I seldom see event loop 
issues in my own apps because I simply work around them wherever 
possible (calls to update, after, update idletasks, etc.). It takes some 
trial and error, but once I have a working solution, I don't have to 
revisit it.

What I'd like to do, instead, is assemble some best practices. What do 
you all do to work around these issues? Perhaps we can assemble a thread 
here, and then post some ideas/code to the wiki. Or somewhere else? The 
Tk man pages? Or both?

I'll start with a common solution in my apps: when an app has a sudden 
error and throws up an error dialog (via the "bgerror" command), earlier 
versions of Tk-Cocoa would lock up and prevent the dialog from drawing. 
My solution was to re-define the "bgerror" command to write errors to 
the console. (This is actually more useful in my view.)

#handle errors in Tk
proc bgerror {args} {
     exec syslog -s -l Error "PacketStream: An error occurred: $args"
}

This issue has since been fixed, but I stopped worrying about it after 
finding a viable workaround.

Other comments on this issue are appreciated.

--Kevin

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com