This can be handy for when you still want to handle other events while trying to read a whole line of input. However I'd be interested to know if there are problems. Every now and then servers I have made begin to take 100% of the CPU, but none of my callbacks seem to be getting called (I have debug output pretty much everywhere to try to find things like this). This is frustratingly rare and not reproducable by any means I have tried (Tcl8.3). --
SetokAdditional note: the event loop is still running in the above case. Events are handled fine, so it's not stuck in a while loop or something. Just that it's taking all CPU time it can get. --
Setok
## The same as [gets], except that it works when 'chan' is in non-blocking
## mode and while waiting for input, the event loop is started.
## By Kristoffer Lawson
proc getsBG {chan} {
global tcl-utils::ReadableStatus
# See that index is unique and does not conflict with other eventReads
set i 0
while {[info exists ReadableStatus($chan,$i)]} {
incr i
}
set ReadableStatus($chan,$i) 0
set oldScript [fileevent $chan readable]
fileevent $chan readable [list set ::tcl-utils::ReadableStatus($chan,$i) 1]
set rc -1
# We continue trying to get data until [gets] returns a complete line.
set line ""
while {($rc == -1) && ![eof $chan]} {
vwait ::tcl-utils::ReadableStatus($chan,$i)
unset ReadableStatus($chan,$i)
set rc [gets $chan line]
# dputsVar local line
}
# dputs 5 "eof chan: [eof $chan]"
fileevent $chan readable $oldScript
return $line
}