>  Hi,
> 
>  While reviewing the guts of [fcopy], I realized my half-ignorance
>  about stacked channels. I'm willing to reverse-engineer that too of
>  course ;-) but I'd appreciate help about "the big picture": are they
>  used beside (1) the TLS extension and (2) Andreas' script-level
>  transform channel type ?

There is also the Trf extension, howver I do not know if anybody is using
its commands in stacked channel mode or not.

>  The question is in fact related to the test suite: since TLS is an
>  extension, it cannot be formally included in the core test suite, yet
>  it could be very sensitive to tweaks in the core... And more
>  generally, what is the accepted way of stress-testing the stacked
>  channel subsystem ?
> 
>  I did notice iogt.test, where I can see the following comments:
> 
>   test iogt-3.0 {Tcl_Channel valid after stack/unstack, fevent handling} > 	{testchannel un
knownFailure} {
>      # This test to check the validity of aquired Tcl_Channel references is
>      # not possible because even a backgrounded fcopy will
>  immediately start
>      # to copy data, without waiting for the event loop. This is
>  done only in
>      # case of an underflow on the read size!. So stacking
>  transforms after the
>      # fcopy will miss information, or are not used at all.
>      #
>      # I was able to circumvent this by using the echo.tcl server
>  with a big
>      # delay, causing the fcopy to underflow immediately.
> 
>  Andreas, shouldn't this one be changed in the light of  1932639 ?

After looking over the test I do not think that the unknownFailure was added
for the fcopy stuff. The last comments indicate that the fcopy problem was
overcome. Note that iogt-4.0, -5.0 are marked the same, albeit without any
comments. I think that the system gave me a different order of actions than
expected and it was not clear why/how.

Even so, not having touched this in a very long time I believe it is worth a
shot to activate these tests and see what happens now that fcopy -command is
fully async from the beginning.


>  (Sorry for violating the "no details here" rule again, but when things
>  are thus interpenetrated it is hard to restrict them to one single
>  tracker entry).

--
	Andreas Kupries <andreask@[...].com> 
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122



-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Register now and save $200. Hurry, offer ends at 11:59 p.m., 
Monday, April 7! Use priority code J8TLD2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core