Tcl Source Code

If I am doing an [fcopy] from chan1 to chan2 I cannot use a 
readable fileevent for chan1. This is completely understandable, 
but why does it not work the other way round? I would like to copy 
data from chan1 but also react to any responses coming from 
chan2 as soon as they arrive. However, this is not possible. 
Neither is setting a writable fileevent for chan1.

Committed a clarification to fcopy.n [check-in a6e8d5d50c]. Thanks for feedback.

> BTW, can I multiplex a single source into
> multiple destinations with fcopy (as tee(1)
> would do)? Should I be able to?

Not "out of the box", because async fcopy is a simple-minded "byte noria", that essentially spends its life alternating a readable and a writable fileevent (in C), guaranteeing no accumulation in memory. The noria requires to be alone fiddling with fileevents in that direction, otherwise there would be a race on the read side.

If instead you want to "fork the flow", simply do a single fcopy towards a synthetic channel (refchan) that duplicates.

Though the fix (improvement) was committed into Tcl C-code, the documentation was never updated. The man-page for fcopy(n) still states:

You are not allowed to do other I/O operations with inchan or outchan during a background fcopy.

The above sentence should be clarified and an example of bi-directional fcopy be added.

BTW, can I multiplex a single source into multiple destinations with fcopy (as tee(1) would do)? Should I be able to?

Logged In: YES 
user_id=75003
Originator: NO

And Alexandre is now on the developer's list for Tcl, currently only for 'Tracker Admin'. That should allow him to attach patches to other tracker item than his own.

Logged In: YES 
user_id=75003
Originator: NO

Functionality committed to 8.4, 8.5, and head branches.
Test case will follow.

Logged In: YES 
user_id=75003
Originator: NO

True that.

Logged In: YES 
user_id=80530
Originator: NO


let's just add ferrieux
to the Developers list so
he can attach patches.

If his worthy contributions
keep up, a maintainer hat
for him may be in the mail.
:)

File Added - 273293: fcopy-dual.tar.gz

Logged In: YES 
user_id=75003
Originator: NO

File Added: fcopy-dual.tar.gz

Logged In: YES 
user_id=75003
Originator: NO

Send them to me and I as maintainer should be able to attach them.

Logged In: YES 
user_id=496139
Originator: NO

Fixed.

Attaching a patch (including the two other recent fixes to fcopy) refining the blindly symmetrical busy test (non-null csPtr) by a direction-specific one.
The refined test is:

 #define BUSY_STATE(st,fl) \
    ((st)->csPtr && \
     ( (((fl)&TCL_READABLE)&&((st)->csPtr->readPtr==(st)->topChanPtr)) || \
       (((fl)&TCL_WRITABLE)&&((st)->csPtr->writePtr==(st)->topChanPtr))))

Also attaching 4 test scripts:
 - fev[12].tcl: run in two separate tclsh's, use an async fcopy and a reverse fileevent readable.
 - inetc.tcl,noria.tcl: run in three tclsh's: one noria and two inetcs, this establishes a bidirectional fcopy: anything typed into one inetc is displayed on the other one and vice versa.

Last minute: heck, I cannot attach any files since I'm not the reporter ! What can I do ?

Logged In: YES 
user_id=137542

The manpage clearly states that no IO can be done with either channel. 
Presumably that would include reading from the outChan. In fact, I have seen 
this occur where I get something like a "channel is busy" error. I am not sure if 
your example is good for testing this as in such a small case it will likely have 
written out all data before the fileevent is triggered.

Logged In: YES 
user_id=19214

I'm not sure I follow ... the following code seems to work
as I would expect it to, in a recent 8.5 - regardless of
whether the [fileevent] occurs before or after the [fcopy].

Is the problem that a readable event won't trigger while the
[fcopy] is active (that is, before Done is called?)

proc readable {sock} {
    puts stderr "R: [gets $sock]"
}

proc done {args} {
    puts stderr "DONE: $args"
}

proc accept {sock args} {
    puts stderr "accept $args"
    set fd [open fcopy-socket.tcl r]
    fcopy $fd $sock -command done
    fileevent $sock readable [list readable $sock]
}

socket -server accept 9999

vwait forever