Quantcast

How to move forward with Tk-Cocoa event loop issues

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

How to move forward with Tk-Cocoa event loop issues

Kevin Walzer-5
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

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Tcl-mac mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-mac
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to move forward with Tk-Cocoa event loop issues

Adrian Robert-3
Hi Kevin,

I really appreciate the work you are doing, and I understand wanting to clean up, cut losses, and move on, but I don't think it's good to sweep such bug reports under the rug.

We might not have the combination of time and expertise right now to fix these problems, but hopefully sooner or later we will.  At that time we'll want as clear descriptions of the issues as possible, and the simplest code available for reproducing them.  Closing bugs only makes them less visible and less likely to be found.  Duplicates will probably submitted, scattering useful information.  Or worse, the "it's as good as it's going to get, we're not going to fix it" message will discourage people from submitting bugs, trying to fix them, or, ultimately, from using Tk at all as a cross-platform solution.

I don't object to systematically documenting the best ways for working around Tk-Cocoa's problems, but let's leave open bugs open and put efforts into creating minimal reproduction scripts if nothing else.  (Side note, I tried on and off for more than a year to "work around" Tk-Cocoa's bugs, before going the route of altering my application's functionality on the Mac platform to get it out the door.)

-Adrian



On 2012/10/01, at 22:12, Kevin Walzer <[hidden email]> wrote:

> 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
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Tcl-mac mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tcl-mac


------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Tcl-mac mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-mac
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to move forward with Tk-Cocoa event loop issues

Kevin Walzer-5
Hi Adrian,

> I really appreciate the work you are doing, and I understand wanting to clean up, cut losses, and move on, but I don't think it's good to sweep such bug reports under the rug.

Fair enough. I've re-opened the bug in question so that it will reappear
in searches and for comments, but I've left its status as "won't fix"
because I'm not persuaded that it is, in fact, fixable.

> We might not have the combination of time and expertise right now to fix these problems, but hopefully sooner or later we will.  At that time we'll want as clear descriptions of the issues as possible, and the simplest code available for reproducing them.  Closing bugs only makes them less visible and less likely to be found.  Duplicates will probably submitted, scattering useful information.  Or worse, the "it's as good as it's going to get, we're not going to fix it" message will discourage people from submitting bugs, trying to fix them, or, ultimately, from using Tk at all as a cross-platform solution.

It is indeed unfortunate that there are only a handful of folks with the
combination of time, interest, and expertise to actively work on Tk at a
low level. It's understandable, though, because the barrier to entry in
terms of expertise is very high: it took me four or five years to
develop any competence at all with Tk and Cocoa at the C level. And on
the other side, there are other folks in this community with more
expertise than me, but with less time and/or interest: they just want Tk
to work but don't want to have to dig deeply into its internals. In this
regard I am especially grateful to you for the patches you've recently
submitted.

As far as choosing another cross-platform framework instead of Tk, I
also understand this argument, but I choose Tk anyway because it's
easier to extend than any other cross-platform framework. Adding
Services support, AppleScript support, etc. is comparatively easy in Tk:
imagine trying to do something similar with PyQt or wxPython. First
you'd have to dig deeply into the C++ library, then you'd have to figure
out how to wrap that functionality in the higher-level framework.
Doable, but very, very hard, I imagine. It's why I've stayed with Tk
despite its problems.

It would certainly be wonderful if we got some new blood in the
community to work on Tk. One reason I am pessimistic about this is,
apart from Tk lacking the "cool factor" and the Mac-specific bugs being
a turnoff, Tk's C API is increasingly becoming an undocumented "black
art." The best extant resource on Tk's C API that I've seen is Brent
Welch's book, which I learned a lot from, but which only goes through Tk
8.4 and is going on ten years old. The recent new edition of Osterhout's
book skips over Tk's C API with the assertion that "since so few people
work on it, it's not of interest here." Ridiculous.

> I don't object to systematically documenting the best ways for working around Tk-Cocoa's problems, but let's leave open bugs open and put efforts into creating minimal reproduction scripts if nothing else.  (Side note, I tried on and off for more than a year to "work around" Tk-Cocoa's bugs, before going the route of altering my application's functionality on the Mac platform to get it out the door.)
>
I'm sorry for the trouble you had with your own app. And yes, I'll leave
the bug open.

Thanks for the feedback,
Kevin


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

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Tcl-mac mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-mac
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to move forward with Tk-Cocoa event loop issues

Kevan Hashemi
In reply to this post by Kevin Walzer-5
Dear Kevin,

> What I'd like to do, instead, is assemble some best practices.

I find your argument convincing. As it is, my applications already have
serious problems with the Tcl event loop, and the Tk/Carbon event loop,
almost all of which I have worked around by trial and error through
insertion of update, update idletasks, vwaits and after commands. These
commands do not, in my experience, do exactly what the TclTk
documentation tells me they should do, but they almost always seem to
fix the problem.

Every now and then, however, there comes an event-loop problem that I
can't fix. The screen freezes during TCPIP communication, for example,
and these I have submitted as bug reports and they have been fixed. So I
imagine that the same thing will happen with the Tk/Cocoa event loop.

If we have a list of best practices, then people like you, who end up
doing the bug fixes, can first point to this list before you spend your
time looking into something that is supposed to be a bug. Thus I think
this list of best practices is a good idea, and I accept the compromise
you propose.

 From your subsequent answer to Adrian:

 > And on
 > the other side, there are other folks in this community with more
 > expertise than me, but with less time and/or interest: they just want
 > Tk to work but don't want to have to dig deeply into its internals.

Yup, that's me. You are maintaining this code and also using it
yourself. Looking at your portfolio of applications, it seems to me that
you are firmly invested in TclTk on the Mac. Your investment gives your
proposal a guarantee in my mind.

Yours, Kevan

--
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://alignment.hep.brandeis.edu/

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Tcl-mac mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-mac
Loading...