Tcl Source Code

The following script results in an error to the effect that the coroutine is already running.

#! /bin/env tclsh

interp bgerror {} [list apply {{res opts} {
    puts stderr [dict get $opts -errorinfo]
    exit 1
}}]

namespace eval schan {
    namespace ensemble create
    namespace export *
    proc open {} {
        variable chans
        set chan [chan create read [namespace current]]

    }
    proc initialize {chan mode} {
        return [list initialize finalize read watch]
    }

    proc read {chan count} {
    }

    proc watch {chan eventspec} {
        chan postevent $chan $eventspec
    }
}

coroutine c1 apply [list {} {
    set chan [schan::open]
    chan event $chan readable [list [info coroutine]]
    yield
    puts thiswillnotappear
}] 
vwait ::forever

On the "unchained" branch test iocmd-31.9 tests this issue.

This issue remains fixed on the "unchained" branch. The stated rationale for rolling back the fix for this issue, "completely nullifies the purpose of event-driven i/o", is not only false on that branch since event-driven i/o operates as expected, with write events being generated only when the underlying device is writable, but is orthogonal to the issue raised here.

We had a meeting today. Today, it is my duty to close the tickets.
Sorry, the others are not available today. We have to share resources...

Thank you for your comprehension,
Harald

This issue should remain open until [67a5eabbd3d19591] is resolved.

Dear Nathan,

thank you for reporting this documentation issue. Please report it in a different ticket.

Thank you for your comprehension,
Harald

No, the documentation for [chan postevent] does not indicate that this is expected behaviour, so this report should remain open.

Sorry Nathan ! As informed on the core list:

• This is a RFE, not a bug. It will not work with the current design.
• The only way to change this is a TIP

In consequence, it is changed to a RFE and closed with the state "wont fix".

Thank you for your comprehension, Harald

It is not clear to me that this is a duplicate of [d3232b49f2], so I'm reopening it.

Dup of [de232b49f2]

This 'bug-fix' is backed-out, see here for the full motivation. Backout approved by the TCT.

Yes, that's an accurate summary, as the call to Tcl_NotifyChannel is moved into a timer event handler.

Can the patch be described accurately as changing to operations
of the [chan postevent] command from synchronous to asynchronous?

Backed out because of [18f4a94d03]. Therefore re-opening this one.

Fixed in [e066e24f36f67a8d] by using Tcl_CreateTimerHandler() to schedule the call to Tcl_NotifyChannel().

FWIW, some time ago, async fcopy suffered from a similar "premature callback" issue: in some circumstances, where the copy was provably complete, the completion callback fired from within fcopy instead of from the event loop  (despite the async flag).

It was Obviously Wrong, and fixed. I'm tempted to follow your suggestion and propose the same here, though I don't know the details of the refchan enough to be sure of the analogy.

Maybe Andreas could chime in.

This happens because chan postevent calls Tcl_NotifyChannel() instead of scheduling an event, as explained in ef28eb1f15167156c898.

Hum, never mind, simple interp bgerror playing its role, sorry.

Interesting: it's not even a vanilla error, it's uncatchable !
It sorta reaches the default "spit out errorInfo and exit(1)", regardless of any [catch] range.
Digging...

The stack trace of the error is:
 c1
  chan event
   schan::watch
    c1 (boom!)

ie, yield is not even reached.

schan::watch should not immediately call [chan postevent].  Wrapping that in [after 0] removes the crash, but I'm not sure this is correct behaviour for postevent either.

See tcllib or http://chiselapp.com/user/aspect/repository/tcl-hacks/artifact/6cb89e9c9ebb6800 for other strategies (but I now see potentially a similar bug in the chiselapp link ..)