Repository: http://core.tcl.tk/tcl
Change Notification For
[socket -async stall on windows]
Ticket http://core.tcl.tk/tcl/tktview?name=336441ed59c9f49fb2dc5414911f5c90c7acdec3
Artifact http://core.tcl.tk/tcl/tinfo?name=9e5678f685dc7c233b79a508c56b2607760610f2
On 2014-04-29T20:00:01
By oehhar
Changed Fields
closer: nobody
icomment: Andreas has tested the patch on 8.5 and it failed. Here is his
message:
Running our stackato.exe in a loop, simply asking for information from
the target, with https (TLS) active the application hangs after about
14-28 iterations, with about 14 iterations per minute, so within 1 to
2 minutes. Symptom of not accepting ^C is the same as before I should
note.
After activating the --debug-http-log it is not hanging itself within
10 minutes anymore. As that option only activates more output, i.e.
introduces delays this looks as if there is still a race condition
present, old or new.
This means that I will still have to use my fix and branch of Tcl 8.5
for the stackato client, instead of head. Sorry about the bad news.
The rough outline of operations done in the client is:
-1- register tls for https, with http -2- open a https -async socket
to a webserver -3- read some data data, via readable fileevent -4-
close the socket -5- format and print data
Note that the iterations I speak of here are always new stackato
processes, with each doing the above. The iteration does NOT happen in
a single stackato process.
The last time I had to investigate the hang happend inside of TLS,
during the open of the socket, i.e. step 2. The TLS transform does
sync read/writes to perform the TLS handshake, without using
fileevents.
I suspect that this is true this time as well.
login: oehhar
resolution: None
status: Open
username: oehhar

Repository: http://core.tcl.tk/tcl
Change Notification For
[Inadequate fcopy operation]
Ticket http://core.tcl.tk/tcl/tktview?name=1350564fffffffffffffffffffffffffffffffff
Artifact http://core.tcl.tk/tcl/tinfo?name=d4b09244215f4b0c4656002b65e89ea5d434e31a
On 2014-04-28T20:10:44
By ferrieux
Changed Fields
closedate: 2456776.34079354
closer: ferrieux
icomment: > 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.
login: ferrieux

Repository: http://core.tcl.tk/tcl
Change Notification For
[Inadequate fcopy operation]
Ticket http://core.tcl.tk/tcl/tktview?name=1350564fffffffffffffffffffffffffffffffff
Artifact http://core.tcl.tk/tcl/tinfo?name=f23b262b2c02845f2aea653d2968fac248af4388
On 2014-04-28T19:11:13
By mi
Changed Fields
assignee: aku
closedate: 2456776.29946007
closer: mi
comment: 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.
icomment: <p align="justify">Though the fix (improvement) was committed into Tcl
C-code, the documentation was never updated. The man-page for
<tt>fcopy(n)</tt> still states: <blockquote>You are not allowed to do
other I/O operations with inchan or outchan during a background
fcopy.</blockquote> <p align="justify">The above sentence should be
clarified and an example of bi-directional fcopy be added. <p
align="justify">BTW, can I multiplex a single source into multiple
destinations with fcopy (as <tt>tee(1)</tt> would do)? Should I be
able to?
login: mi
severity: Minor