There is a strange problem that only occurs in some notebooks running Windows.
I have a Tcl/Tk application that executes another one using 'open |<command> r+', the pipe returned by open is used to communicate to the standard input/output of the new process.
The second process works fine until any key is pressed when any of its windows owns the focus, then the GUI freezes. But if something is written in its 'stdin' it wakes up, then the key event is received, and everything works again. After that no more key presses causes a freeze.
This pair of Tcl files recreates the error:
##########################################
## File run-hello.tcl
proc read-pipe {pipe} {
if {![eof $pipe]} {
puts [gets $pipe]
} else {
close $pipe
}
}
set pipe [open "| tclsh.exe hello.tcl" r+]
fconfigure $pipe -buffering line
fileevent $pipe readable [list read-pipe $pipe]
package require Tk
button .b -text {Send -wake up-} -command [list puts $pipe {wake up}]
pack .b
##########################################
##########################################
## File hello.tcl
proc read-pipe {pipe} {
if {![eof $pipe]} {
puts [gets $pipe]
} else {
close $pipe
}
}
fileevent stdin readable {read-pipe stdin}
package require Tk
button .b -text Hello -command {puts Hello!}
pack .b
##########################################
This code seems to be correct and it works fine in Unix and most Windows machines, it only hangs in some laptops running Windows.
The laptop were I detected the bug, is a Compaq nc6400. But I know it happened also in an IBM Thinkpad.
I have tested it with some versions of tcl, and the problem has always appeared:
ActiveTcl 8.4.7
ActiveTcl 8.4.15
dqkit 8.4.13
tclkit 8.5.a6
OS version: Windows XP Professional SP2
Other info:
env(PROCESSOR_ARCHITECTURE) = x86
env(PROCESSOR_IDENTIFIER) = x86 Family 6 Model 14 Stepping 8, GenuineIntel
env(PROCESSOR_LEVEL) = 6
env(PROCESSOR_REVISION) = 0e08
tcl_platform(byteOrder) = littleEndian
tcl_platform(machine) = intel
tcl_platform(os) = Windows NT
tcl_platform(osVersion) = 5.1
tcl_platform(platform) = windows
tcl_platform(wordSize) = 4
Logged In: YES
user_id=1556756
Originator: NO
We've gathered some more information about the bug. Maybe you find it useful.
First, we've detected this issue in two other laptop models: Dell Latitude D620 and Toshiba Tecra running Windows. Sorry but we don't have additional information about software versions, apart from the Tcl data given by Pablo.
And also I give you some more details about the workaround found by Pablo. Maybe it gives you some clue. When the child interpreter is blocked, if the parent sends an end-of-line character through the pipe the child unblocks and becomes responsive again. So what we do is to have the parent application sending periodically a keep-alive message to the child. Once the child interpreter has blocked and unblocked, it never blocks again when you use the keyboard.
Kind regards,
Miguel
Logged In: YES
user_id=202636
Originator: NO
The windows console in standard mode blocks when you start entering characters until you enter a new line. I once wrote a console app that created a window and run a message pump and found that I had to switch the console to an event based scheme using SetConsoleMode and then process console input in the messagepump using MsgWaitforMultipleObjects.
I feel sure this an application design issue really. If you could withdraw the console, or switch to ~ENABLE_LINE_INPUT maybe you could fix it.