Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#1295 SSH and threaded Tcl: file events get missed

obsolete: 8.2
closed-duplicate
nobody
5
2014-10-07
2000-10-26
Anonymous
No

OriginalBugID: 2661 Bug
Version: 8.2
SubmitDate: '1999-08-31'
LastModified: '1999-12-17'
Severity: MED
Status: UnAssn
Submitter: techsupp
ChangedBy: hobbs
OS: Solaris
OSVersion: 2.6
Machine: Other
FixedDate: '2000-10-25'
ClosedDate: '2000-10-25'

Name:
Michael Santos

ReproducibleScript:
Channel event handlers are never invoked for a TCP server socket even
though Tcl_DoOneEvent is called to check for all events when the server
is running on a remote machine via ssh. This is a modification of my
previous bug report program. When linked with Tcl compiled with thread
support, the ConnectPort function will never be invoked in response to a
connection, even though the process connecting to the included program
sees that the connection is established. I guess an accept in done on
the underlying socket, but the handler associated with it is never run.
When linked against Tcl without thread support, everything works
correctly. Similarly, if the server is run on a remote machine via rsh
instead of ssh, everything works correctly. Perhaps this is really a
bug in ssh; I don't know.

To test, compile the program below: call it server. ssh into another
machine and run the server in the supplied shell. On the local machine,
fire up Tcl and connect to the server via "socket <remote machine>
50099". ConnectPort will almost always not be invoked. Occassionally,
I have seen it invoked many (20-30) calls to Tcl_DoOneEvent later.

The sample C file follows. The executable takes a single argument that
controls how quickly Tcl checks for events.

#include <stdio.h>
#include <tcl.h>

Tcl_Interp *gInterp;

void
ReadData(ClientData clientData, int mask) {
char buf[256];
fprintf(stderr, "ReadData() called\n");
while (Tcl_Read((Tcl_Channel)clientData, buf, 255) > 0) ;
Tcl_Close(gInterp, (Tcl_Channel)clientData);
}

void
ConnectPort(ClientData clientData, Tcl_Channel new_socket,
char *hostName, int port) {
fprintf(stderr, "ConnectPort() called with hostname %s, port %d\n",
hostName, port);
if (Tcl_SetChannelOption(gInterp, new_socket,
"-buffering", "none") != TCL_OK) {
fprintf(stderr, "Error setting buffering option on TCL socket.\n");
abort();
}
if (Tcl_SetChannelOption(gInterp, new_socket,
"-translation", "binary") != TCL_OK) {
fprintf(stderr, "Error setting translation option on TCL "
"socket.\n");
abort();
}
if (Tcl_SetChannelOption(gInterp, new_socket,
"-blocking", "FALSE") != TCL_OK) {
fprintf(stderr, "Error setting blocking option on TCL socket.\n");
abort();
}

Tcl_CreateChannelHandler(new_socket, TCL_READABLE, ReadData,
(ClientData)new_socket);
}

void
StartServer(ClientData clientData) {
Tcl_Channel socket;
fprintf(stderr, "StartServer() called.\n");
socket =
Tcl_OpenTcpServer(gInterp, 50099, NULL,
ConnectPort, (ClientData)NULL);
if (!socket) {
Tcl_Exit(1);
}
}

int
Tcl_AppInit(Tcl_Interp *interp) {
gInterp = interp;
if (Tcl_Init(interp) != TCL_OK) {
fprintf(stderr, "Tcl failed to initialize.\n");
Tcl_Exit(1);
}

StartServer(NULL);

return TCL_OK;
}

int
main(int argc, char *argv[]) {
int i;

gInterp = Tcl_CreateInterp();
Tcl_AppInit(gInterp);

while (1) {
for (i = 0; i < atoi(argv[1]); i++) ;
fprintf(stderr, "Checking for events.\n");
while (Tcl_DoOneEvent(TCL_DONT_WAIT)) {
/* Empty while loop */
}
}
return 0;
}

ObservedBehavior:
When a server socket is opened on the other end of an ssh connection,
file events are improperly recognized -- usually ignored, but sometime
greatly deferred. It seems to be related to ssh's port forwarding
feature, as connecting with "ssh -x", which disables the X11 forwarding,
leads to correct behavior.

DesiredBehavior:
I would expect that the connection would work regardless of whether ssh
is forwarding X11 traffic and whether or not Tcl is compiled with
threads support. For some reason, only the threaded version seems to be
affected by ssh's X11 port forwarding.

Discussion

  • Jeffrey Hobbs
    Jeffrey Hobbs
    2002-03-22

    • status: open --> closed-duplicate
     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2002-03-22

    Logged In: YES
    user_id=72656

    This appears to be a dup of 219301