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

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