Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#3862 FilterInputBytes/GetInput do not handle EINTR

obsolete: 8.4.14
open
8
2007-12-18
2007-12-05
Jeff Newbern
No

Using tcl8.4.14 on Ubuntu 7.10 (Linux kernel 2.6.22)

In interactive mode, the TCL shell blocks in a read() system call waiting for a command to be typed. If a signal is received, the read() call returns EINTR (see note 1) to indicate that the system call was interrupted.

The code in FilterInputBytes does not test for the EINTR error code -- it treats it like a hard error even though other routines in the same file which use GetInput do handle the EINTR case.

This makes it impossible to use a signal handler with an interactive TCL application. Even if the signal is caught and handled correctly by the application, the interrupted read() syscall will return EINTR and this will be treated like a hard error, dumping me out of the interpreter without a chance to restart the read() call.

The behavior I expect is that TCL should detect the EINTR error code and restart the interrupted read().

In my case, I am installing a handler for SIGINT, so that I can catch and make use of a Ctrl-C from the keyboard to safely abort a long-running command. Unfortunately, it currently has the effect of aborting the entire TCL session as well, due to this bug.

Thanks,
Jeff Newbern
jnewbern@bluespec.com

Note 1: Actually on my system it returns ERESTARTSYS due to a kernel bug, but this is a separate issue from the TCL bug, which remains even after the kernel is fixed.

Discussion

  • Logged In: YES
    user_id=585068
    Originator: NO

    I agree this should be fixed. GetInput is also in need of some cleanup. It looks like it has evolved through several generations of hacks.

    We should probably also audit the rest of the sources for invalid handling of EINTR errnos when using read().

     
    • milestone: --> obsolete: 8.4.14
    • priority: 5 --> 8