Tcl Source Code

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.

Logged In: YES 
user_id=72656

I wimped out and decided not to make these changes for 
8.4.5.  It spanned a few changes, which indicates it had it's 
little subtleties.  For reference, the changes when in from 
[1.114 to 1.117), in case we want to backport for 8.4.6.

Logged In: YES 
user_id=148712

Jeff: incorporate to 8.4 branch? This should really be a
safe patch, but it has not been stress tested. Also kinda
late ...

Logged In: YES 
user_id=79902

Reopening; still need assessment of whether this is a
candidate for 8.4

File Deleted - 67633:

File Added - 67664: async.patch

Logged In: YES 
user_id=148712

Two small errors fixed in head incorporated to the patch.

File Added - 67633: async.patch

Logged In: YES 
user_id=79902

Applied with a few extra tweaks.  Is the updated patch a
candidate for 8.4?

async-4.2 and 4.3 fail on Linux.  No idea why.

File Added - 67626: async.patch

Logged In: YES 
user_id=148712

Attached a patch that checks for pending asyncs every 16th
instruction; the patch includes the tests of asynctest.patch.
Note that the tests require a threaded build to run.
Please review.

Logged In: YES 
user_id=79902

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

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

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

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.)

File Deleted - 51826: 



File Added - 52213: asynctest.patch

Logged In: YES 
user_id=99768

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

Logged In: YES 
user_id=148712

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

File Added - 51826: async.patch