Menu
▾
▴
[Tcl-bugs] [ tcl-Feature Requests-525783 ] Need optional full flush on [exit] for serial
|
From: SourceForge.net <no...@so...> - 2003-10-22 17:54:52
|
Feature Requests item #525783, was opened at 2002-03-05 04:03 Message generated for change (Comment added) made by dkf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=360894&aid=525783&group_id=10894 Category: 25. Channel System Group: None Status: Open Resolution: Remind >Priority: 5 Submitted By: Don Porter (dgp) Assigned to: Donal K. Fellows (dkf) Summary: Need optional full flush on [exit] for serial Initial Comment: Previously reported as Tk Bug 525778, tclsh has the same problem on Solaris 8: # FILE: test.tcl for {set i 0} {$i < [lindex $argv 0]} {incr i} { puts $i } $ tclsh8.3 test.tcl 5 0 1 2 3 4 $ tclsh8.4 test.tcl 5 <no output> $ tclsh8.3 test.tcl 500 0 ... 499 $ tclsh8.4 test.tcl 5 0 ... 358 $ I'm assigning to "Channel System" because I think that must be where the bug lies. tclsh calls Tcl_FSEvalFile() within Tcl_Main() and wish calls Tcl_EvalFile() within Tk_Main(), so they don't have code in common, but show the same misbehavior. ---------------------------------------------------------------------- >Comment By: Donal K. Fellows (dkf) Date: 2003-10-22 16:27 Message: Logged In: YES user_id=79902 Dropping the prio; it's in the TIP process now ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2003-10-17 11:46 Message: Logged In: YES user_id=79902 See TIP#160 http://purl.org/tcl/tip/160 ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-06-25 15:34 Message: Logged In: YES user_id=80530 restored assignements lost in Tracker move. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2002-06-25 15:30 Message: Logged In: YES user_id=79902 This is really an FRQ now ---------------------------------------------------------------------- Comment By: Rolf Schroedter (schroedter) Date: 2002-06-24 12:08 Message: Logged In: YES user_id=99573 As the author of the recent serial port changes (TIP#35) I'm supporting Donal's proposal of an additional fconfigure option: fconfigure $fd -onclose wait/discard This option should be general for *all* Tcl channels with the obvious default=wait (or flush). Please note that this cannot be done by the channel driver's [fconfigure] part because the channels driver cannot easily distinguish between a "normal flush" and a "flush-on-close" situation. Currently Tcl's channel system performs a blocking write before closing/exiting - Put the channel into blocking mode and - Write out all pending data This should be avoided by calling [fconfigure $chan -onclose discard]. It's really bad that a channel intentionally configured by the user as non-blocking becomes blocking at close. I assume that this could also be useful for other channels (sockets ?). Rolf. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2002-06-24 11:08 Message: Logged In: YES user_id=79902 The current situation results in bugs for the smallest number of people; a lot more people use Tcl from a terminal on Unix than use serial ports under Unix! A comment of mine below (the -onclose option) contains the germ of a TIP to fully resolve this matter (I know of no way to determine what the best action is by default, and that is really an OS design decision that I agree with in principle, so this really belongs in the hands of programmers) and I might get around to doing something about it in the future. Or I might not. Either way, no reason to hold back the b1 release waiting on this. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-06-22 01:30 Message: Logged In: YES user_id=80530 hot potato back to you. all my problems are resolved. ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2002-06-21 18:23 Message: Logged In: YES user_id=75003 In a way. See below. Jeff did provide and commit a fix, but he is not completely satisfied with it. The std* channels have the correct behaviour, but true serial channels might not get completely auto-flushed when exiting. So the bug as reported is fixed, with problems in a different area. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-06-21 18:03 Message: Logged In: YES user_id=80530 I can no longer reproduce the problem with the HEAD sources. Is this matter closed? ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2002-05-10 18:05 Message: Logged In: YES user_id=75003 I remember that Jeff did some changes ... Changelog ... 2002-03-05 Jeff Hobbs <jeffh@ActiveState.com> * unix/tclUnixChan.c: initial remedy for [Bug #525783] flush problem introduced by TIP #35. This may not satisfy true serial channels, but it restores the correct flushing of std* channels on exit. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-05-10 17:53 Message: Logged In: YES user_id=80530 Did this get resolved? ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2002-03-06 13:18 Message: Logged In: YES user_id=79902 The problem with tcflush on exit is that it can nuke output in the OS buffers that came from stderr (say "sayonara" to debugging messages!) Further investigation found that this could still happen even with some fairly elaborate measures to prevent it (like barring tcflush from operating on FDs 0, 1 and 2) because it is a race between the data being grabbed by the tty and displayed, and the tcflush on an unrelated channel (you'll need the [open [exec tty]] addition mentioned below to enable this behaviour.) So as to make sure that people just using Tcl normally would not see the problem, and given the short timescale we were working on w.r.t. the 8.4a4 release, the tcflush was changed to a tcdrain (whose behaviour meets more what non-serial people think of by a flush!) even though this is clearly not what you were intending when you wrote the code. A better fix will require application-input (since both behaviours are right in certain circumstances) which means there's room for another thing to [fconfigure], e.g. fconfigure $fd -onclose wait/discard (Reset semantics probably ought to be handled in the same way, because they are equally surprising when they hit the controlling terminal and both styles of behaviour can be considered to be correct in some circumstances.) ---------------------------------------------------------------------- Comment By: Rolf Schroedter (schroedter) Date: 2002-03-06 12:48 Message: Logged In: YES user_id=99573 This problem was probably introduced by two changes: 1. stdin/stdout are now handled by the TTY driver 2. The TIP#35 changes (Add serial port handshake support) There is no doubt, that TCL-exit should not stall if a serial port output is blocked. This can happen with handshake support. This could also happen even before the TIP#35 changes, when the serial port handshake is activated by using "stty" settings. At exit the channel driver sets all unflushed channels to blocking mode and waits until the output is flushed (maybe forever). That's why the serial port driver now calls "tcflush". For a serial port this is okay, for stdin/stdout this maybe bad. Anyway Tcl's behaviour on exit needs further discussion. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2002-03-05 21:01 Message: Logged In: YES user_id=72656 Attached is my recommend patch (already commited for others to test) to 8.4a4. This removes use of tcflush and reverts to always calling FileOutputProc for now. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2002-03-05 20:07 Message: Logged In: YES user_id=72656 A much more reliable test script is: set size [lindex $argv 0] if {![string is int -strict $size]} { set size 100 } for {set i 0} {$i < $size} {incr i} { puts $i } puts stderr done by adding in the data on the extra channel, that seems to add enough perturbation to the tty's to always show the bug. However, simply changing "tcflush(...)" to "tcdrain((fd))" solves all the problems that I can repeat. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2002-03-05 16:46 Message: Logged In: YES user_id=79902 However, things still foul up if you add open [exec tty] to the script. Need fstat() to detect and avoid that. :^( ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2002-03-05 16:40 Message: Logged In: YES user_id=79902 That was only a partial fix; here's a better one ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2002-03-05 11:22 Message: Logged In: YES user_id=79902 Easy fix: exclude stdout and stderr from the magical flushing in TtyCloseProc() using the attached patch. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2002-03-05 09:50 Message: Logged In: YES user_id=79902 This looks to be TIP#35 related (which stopped serial lines from being flushed on [close] because the operation might block indefinitely), combined with other changes which made stdio channels be recognised as serial channels when used interactively. Both of these make perfect sense in themselves, but they interact badly. Yuck. I suppose the correct thing to do is to do the flush on close only for stdio channels to ttys; i.e. when the fd is 1 or 2... ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-03-05 06:29 Message: Logged In: YES user_id=80530 Confirmed. The changes to unix/tclUnixChan.c on 2002-Feb-27 are what broke things. If this can't be fixed quickly, I recommend reverting to Revision 1.29 before releasing 8.4a4. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-03-05 05:55 Message: Logged In: YES user_id=80530 Sources on Feb 15 worked fine too. This is a recently introduced issue. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-03-05 04:35 Message: Logged In: YES user_id=80530 tclsh 8.4a3 works properly, so the bug has been introduced since that release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=360894&aid=525783&group_id=10894 |