Menu

#1364 TCL Script from Scriptics examples increases system load and

obsolete: 8.3
closed-invalid
nobody
3
2002-01-16
2000-10-26
Anonymous
No

OriginalBugID: 6298 Bug
Version: 8.2
SubmitDate: '2000-09-22'
LastModified: '2000-10-25'
Severity: SER
Status: UnAssn
Submitter: techsupp
OS: Linux-SuSE
OSVersion: Any ...
Machine: Linux and Solaris (several version show same bug)
FixedDate: '2000-10-25'
ClosedDate: '2000-10-25'

Name:
Claus-Peter Rückemann

Extensions:
None for this bug.

Comments:
Look at the comp.lang.tcl.

ReproducibleScript:
http://dev.scriptics.com/software/plugin/engraved.html

Mail on comp.lang.tcl from Thu, 21 Sep 2000 14:34:04 +0200

clicking B3 on raising text several times stops this script
from working. instead the system load goes up. Script must
be canceled. This is fact on standalone in wish4.x, wish8.2 ...
as well as in the tclplugin 2.x. It will hang Netscape on all tested
systems when used inside plugin.

ObservedBehavior:
Raising text is not raising anymore after clicking and moving the mouse.
Sometimes Raising text moves to southeast before hanging.
This is might be a coding problem inside the script due to timing?

DesiredBehavior:
Raising text should not hang ;-)
Is B3 bound to anything, I cannot see this inside
the script. So why do such events happen to
hang the script?

Discussion

  • Donal K. Fellows

    • priority: 5 --> 3
    • milestone: 102429 --> obsolete: 8.3
     
  • Donal K. Fellows

    Replicated on Win32 with 8.3.0 standalone, and confirmed as not really being a Tk bug (unless it is the presence of Tk which is exacerbating things; hard to tell without the appropriate toolset.)

    This bug is simply due to event overload;so many timer events are waiting to be serviced that screen update events are getting *extremely* delayed, though they should eventually get some time. It might take rather a long time for the queue to unblock though.

    You can fix the script mentioned by making sure there is only one fade-related event and one raise-related event going at once (there are other related issues too - the script is frankly quite buggy,) but a more general fix would impose some kind of limit on the after command itself. Hard to say exactly what it should do though, since legit scripts could have a lot of timer events too. :^(

     
  • Donal K. Fellows

    • labels: 104246 --> 33. Safe Base
     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2002-01-16

    Logged In: YES
    user_id=72656

    Since this is just a script issue, I'm closing this.

     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2002-01-16
    • status: open --> closed-invalid