[Tcl-bugs] [ tcl-Bugs-746722 ] Tcl_AsyncMark not delivered in tight loops

[SourceForge.net <no...@so...>]

Bugs item #746722, was opened at 2003-05-31 21:12
Message generated for change (Comment added) made by dkf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=746722&group_id=10894

Category: 46. Bytecode Compiler
Group: 8.5a0
Status: Open
Resolution: None
Priority: 8
Submitted By: Kevin B KENNY (kennykb)
Assigned to: miguel sofer (msofer)
Summary: Tcl_AsyncMark not delivered in tight loops

Initial Comment:
If a bytecoded code sequence contains a tight loop such as

while {1} {}

(in other words, the loop contains no TCL_INVOKE* bytecodes
when compiled), then async events requested in the current
interpreter are not delivered.

Attached patch contains two test cases, one that works, and
one that goes into an endless loop.


----------------------------------------------------------------------

>Comment By: Donal K. Fellows (dkf)
Date: 2003-11-10 21:17

Message:
Logged In: YES 
user_id=79902

Noting that this issue effectively has to be solved for
TIP#143 to be implementable.

----------------------------------------------------------------------

Comment By: miguel sofer (msofer)
Date: 2003-11-07 15:53

Message:
Logged In: YES 
user_id=148712

Only in loops does not solve all issues; consider
   proc runLong args         [string repeat "set x [string repeat a 2000]\n" 9876543]
   runLong
No async will be delivered while runLong is running, even if
we fix the loops. This argues for option 1, I guess

----------------------------------------------------------------------

Comment By: miguel sofer (msofer)
Date: 2003-09-15 00:45

Message:
Logged In: YES 
user_id=148712

Option (0): check for async tasks at the top of the TEBC
loop, after every instruction. Easiest, definitely overkill,
probably unacceptable performance loss

Option (1): special bytecode for "command start" or "command
end". Easiest, performance? Can skip it for INST_EVAL,
INST_INVOKE and INST_EXPR as they do the right thing already.

Option (2): special bytecode emitted in every loop (and also
after every, say, fifth command)

Option (3): special bytecode emitted in every tight loop.
Best, tougher to implement as the compiler has to study the
"tightness" of the loops. A suitable definition could be: a
loop is tight if it has none of the previously mentioned
instructions. Also requires a solution for long non-loop bcc
sequences

Option (1) is the cleanest/easiest in my opinion. Never got
around to code it and time it


----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2003-09-14 22:57

Message:
Logged In: YES 
user_id=79902

Would a suitable fix be to add a new bytecode whose sole job
is to call the appropriate Tcl_Async* stuff?  Then we could
modify the compiler to insert this new opcode when
appropriate (either in every loop - most easily done IMO -
or if we detect that the loop body contains no opcodes that
trigger checking for async events - the minimal requirement.)

----------------------------------------------------------------------

Comment By: Kevin B KENNY (kennykb)
Date: 2003-06-04 23:22

Message:
Logged In: YES 
user_id=99768

Test cases revised to try to improve failure mode - was an infinite loop

----------------------------------------------------------------------

Comment By: miguel sofer (msofer)
Date: 2003-06-04 21:04

Message:
Logged In: YES 
user_id=148712

The tests in the patch pass with the current HEAD - i.e.,
they do not expose the bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=746722&group_id=10894