#1297 Tcl's fileevent callback on a socket does not work the same

obsolete: 8.2.1

OriginalBugID: 3319 Bug
Version: 8.2.1
SubmitDate: '1999-11-05'
LastModified: '1999-11-11'
Severity: MED
Status: UnAssn
Submitter: techsupp
ChangedBy: hobbs
OS: Linux-Red Hat
OSVersion: RedHat 5.2 (intel)
FixedDate: '2000-10-25'
ClosedDate: '2000-10-25'

Mo DeJong

# First, start the "server" and listen for connections.
# When a connection arrives just close the socket.

set port 6789

proc incomingConnection { stream addr port } {
puts "incomingConnection from $addr $port"
close $stream

set server [socket -server incomingConnection $port]

# Now create the "client" socket which makes a connection
# This causes the error {error writing "sock7": broken pipe}

proc canWrite { } {
global socket
if {[eof $socket]} {

puts "Writing to socket"
puts $socket "CLOSE"

set socket [socket localhost $port]
fconfigure $socket -buffering line -blocking 0
fileevent $socket writable canWrite

vwait forever

This generates an error on UNIX systems when the socket is closed on the
server side. The client tries to write when it gets a fileevent writable
event, and this generates and during the write() call because the socket
was closed.

It does not work on these systems:
RedHat Linux 5.2 with Tcl 8.2.1
Solaris 5.6 with Tcl 8.2.1
IRIX 6.2 with Tcl 8.2.1

But under NT with Tcl 8.2.1, the extra fileevent
callback is not generated.

A fileevent writable callback should not be generated on a closed socket
under UNIX systems.

Newsgroup reports indicate that NT has the incorrect behavior.
-- 11/11/1999 hobbs


  • Donal K. Fellows

    It looks to me like the behaviour described as being erroneous is quite possible, since the [socket] command (as written) returns a connected socket, meaning that the server will have had a chance to close the socket off. Either the socket being opened or being closed would be sufficient reason to trigger the writable callback (which is also called when the socket is in an error condition, e.g. closed.)

    The real question is why are no callbacks being performed for the channel at the Tcl end under Windows?

  • Gerhard Hintermayer

    I thought the right way to use callbacks is always to check for eof on both readable and writable channels, that's how all my scripts do and I don't have any problems with that. The man page is quite clear about that for readable channels and not so clear for writable, but I think eof _is_ an error condition.

  • Don Porter

    Don Porter - 2001-03-31
    • labels: 104250 --> 27. Channel Types
  • Donal K. Fellows

    • assigned_to: nobody --> andreas_kupries
  • David Gravereaux

    • assigned_to: andreas_kupries --> davygrvy
  • David Gravereaux

    Logged In: YES

    IMO, as the generic layer can use the concept of 2 uni-
    directional channels, the single bi-direction type of a socket
    needs to force eof from both sides and is the responsibility of
    the driver.

    The [eof] command is ONLY for the read side, not the write
    side. But this doesn't mean checking for [eof] within a write
    callback is wrong. This extra fileevent can be added.

  • David Gravereaux

    • assigned_to: davygrvy --> andreas_kupries
  • David Gravereaux

    Logged In: YES

    Andreas, did your recent patch fix this?

  • Donal K. Fellows

    Logged In: YES

    Andreas is on vacation (and away from Internet) until
    January. Good for him, but not quite so good for turnaround
    time on this bug... :^)

  • Don Porter

    Don Porter - 2006-03-10

    Logged In: YES



Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks