This may be more than one problem. For now, I am
filing it all here.

First, the code:

Server
----
proc bgerror {args} {
puts "bgerror args: $args"
puts "bgerror open channels [file channels]"
}

proc CopyDone {in out bytes {error ""}} {
if { $error != "" } {
puts "Error: $error"
}
close $in
close $out
puts "$bytes bytes, open channels [file channels]"
}

proc Cntr {sock args} {
set fl [open A_BIG_FILE r]
# close $sock
# fconfigure $sock -buffersize 10
fcopy $fl $sock -command [list CopyDone $fl $sock]
}

socket -server Cntr 8070

vwait forever
----

"Client"
----

set sk [socket localhost 8070]
fconfigure $sk -buffersize 10
set line [read $sk 5]
puts $line
close $sk
----

It's worth trying other methods of interrupting
comunication with the server. Programs such as telnet
and netcat work for this.

The Problem(s)

The easiest problem to observe can be observed under
Linux. Uncomment the 'close $sock' line in the server,
and connect to the server with the 'client'. I see
something like this, on multiple connects:

@ashland [~/tmp] $ strace -o foobar tclsh ./fcopy.tcl
bgerror args: {can not find channel named "sock4"}
bgerror open channels stdin file5 stdout stderr sock3
bgerror args: {can not find channel named "sock4"}
bgerror open channels stdin file5 stdout file6 stderr sock3
bgerror args: {can not find channel named "sock4"}
bgerror open channels stdin file5 stdout file6 stderr
file7 sock3
bgerror args: {can not find channel named "sock4"}
bgerror open channels file8 stdin file5 stdout file6
stderr file7 sock3
bgerror args: {can not find channel named "sock4"}
bgerror open channels file8 stdin file9 file5 stdout
file6 stderr file7 sock3
bgerror args: {can not find channel named "sock4"}
bgerror open channels file8 stdin file10 file9 file5
stdout file6 stderr file7 sock3

The strace shows that the fd's are not getting closed.

#2

On windows (XP in my case), comment out the close
statement in the server, and run the 'client' multiple
times. In some cases, it calls the callback with an
error, but other times it does not. Over time, it can
be seen that the channels are leaking.

Comments

I don't know what the correct behavior should be in all
cases. The man page does say that:

You are not allowed to do other I/O operations
with inchan
or outchan during a background fcopy. If either
inchan or
outchan get closed while the copy is in
progress, the cur­
rent copy is stopped and the command callback is
not made.
If inchan is closed, then all data already
queued for
outchan is written out.

It doesn't specify what happens other than that,
though. I suppose we could just declare that 'bad
things happen', and leave it at that, but that doesn't
feel very satisfactory to me. I expect Tcl to be more
robust than that.