Tcl Source Code

View Ticket
Login
Ticket UUID: 219333
Title: TCP ChannelHandler stops working sometimes
Type: Bug Version: obsolete: 8.3
Submitter: nobody Created on: 2000-10-26 05:10:53
Subsystem: 27. Channel Types Assigned To: nobody
Priority: 7 High Severity:
Status: Closed Last Modified: 2001-04-01 01:42:52
Resolution: Fixed Closed By: dgp
    Closed on: 2001-03-31 18:42:52
Description:
OriginalBugID: 4825 Bug
Version: 8.2.1
SubmitDate: '2000-04-03'
LastModified: '2000-10-25'
Severity: CRIT
Status: UnAssn
Submitter: techsupp
OS: Windows NT
OSVersion: NT 4.0 sp4
Machine: PII 350, 128mb RAM
FixedDate: '2000-10-25'
ClosedDate: '2000-10-25'


Name:
Bob Bawn

Extensions:
b;t24, itcl3.1.0 (w/ itk, iwidgets)

Comments:
I just tried if with 8.3.0 and observed the same behavior. I tried
    bumping up the sockets SNDBUF on the server side - no change. I tried
    hacking the tcl win source to load WS2_32.DLL instead of WINSOCK.DLL -
    no change(I have since been told that that shouldn't matter...)

ReproducibleScript:
Here's the chunk of C code that creates the handler from a socket descriptor:

// Make and register a Tcl Channel around the socket so that we can
// use Tcl_CreateChannelHandler to register our message handler 
// callback in a platform-independent fashion 
m_papiChannel = Tcl_MakeTcpClientChannel((ClientData) sd);
Tcl_RegisterChannel(m_interp, m_papiChannel);

// Handle async reply with PapiAsyncHandler(), use object id
// for client data so we know which instance the
// reply is for 
Tcl_CreateChannelHandler(m_papiChannel, TCL_READABLE | TCL_EXCEPTION, 
PapiAsyncHandler, (void *) GetId());

ObservedBehavior:
In my app, the Tcl client (on NT) receives frequents (~30 per second) asynchronous messages over the socket in question from a C program on a FreeBSD server. Normally, everything is fine, but when the client box has a big network load (e.g. 2 ftp transfers) my app behaves as if the socket is never becoming readable. The server's write() eventually fails with an EAGAIN, presumably because its send buffer filled up. The server then closes the socket - my channel handler is still not called (even though it would be when the socket was closed under normal conditions). I don't know much about win32 but my suspicion is that there is some sort of deadlock/timing type of problem. It seems similar to bug #3409.

DesiredBehavior:
- ChannelHandler always gets called when socket becomes readable
- server close() always invokes the ChannelHandler
User Comments: hobbs added on 2001-03-31 07:36:30:
Logged In: YES 
user_id=72656

See fix in patch 410674