[Tcl-bugs] [ tcl-Bugs-1845108 ] FilterInputBytes/GetInput do not handle EINTR

[SourceForge.net <no...@so...>]

Bugs item #1845108, was opened at 2007-12-05 15:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1845108&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 25. Channel System
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jeff Newbern (jnewbern)
Assigned to: Andreas Kupries (andreas_kupries)
Summary: FilterInputBytes/GetInput do not handle EINTR

Initial Comment:
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
jne...@bl...

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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1845108&group_id=10894