threaded tcl crash

threaded tcl crash

Post by yahalom » Thu, 11 Dec 2003 16:38:44


I am using threaded tcl8.4.4 on win 2000 server. I have a server
application that recieves request via sockets and post them to working
threads. it works fine but when I make load tests the threaded tcl
stops after a while with no error.
how can I debug it?
is it tcl problem or operation system problem?

threaded tcl crash

Post by David Grav » Thu, 11 Dec 2003 17:27:22

operating system problem (period). The problem is network I/O under the
hood using winsock's WSAAsyncSelect. It's just awful, plain and simple.
For an improved winsock channel driver for Tcl, try:

If you can overrun its listening socket, I'll be extremely surprised. But
if you can get it to error, just use the -ovlpd switch to the [socket2]
command and increase the count. Personally, I like 200 for a production
server. It defaults @ 50. And as I discovered, anything above 10 seems

David Gravereaux < XXXX@XXXXX.COM >
[species: human; planet: earth,milkyway(western spiral arm),alpha sector] :S.877:
S.877 passed, get ready for the SPAM onslaught like never seen before...
Opt-Out places the burden on the receiver. Opt-In is the future.


threaded tcl crash

Post by yahalom » Fri, 12 Dec 2003 14:26:02


I have a sever application that accepts socket requests and post them
to worker threads. it works fine but when I do load tests at a certain
time the tcl shell exists (with no error).

I use tcl 8.4.4 on windows 2000 server.
how can I debug it (the crash is on the tcl shell level)?

threaded tcl crash

Post by yahalom » Wed, 17 Dec 2003 15:48:20

I found that it is a pipe open/close problem and not winsock problem.
when a pipe is opened to an exe and another thread closes another pipe
at the same time, tcl crashes. I made locking around this area and it
works fine. I posted bug report on sourceforge tcl.
can the iopcsock work with threads and chanshare (package that allows
to pass socket channel to the worker threads)?

threaded tcl crash

Post by David Grav » Wed, 17 Dec 2003 16:14:25

No. I've talked to Andreas Kupries about why it can't and eventually when
a version 4 of the channel driver system can come out (about freeking
time), it can be fixed. This a VERY generic problem with the channel
David Gravereaux < XXXX@XXXXX.COM >
[species: human; planet: earth,milkyway(western spiral arm),alpha sector]

threaded tcl crash

Post by David Grav » Wed, 17 Dec 2003 16:57:29

Here's why.. The driver needs to know of a cut and splice. It would look
like this, if it existed:

/*static Tcl_DriverCutProc IocpCutProc;
static Tcl_DriverSpliceProc IocpSpliceProc;*/

Tcl_ChannelType IocpChannelType = {
"iocp", /* Type name. */
TCL_CHANNEL_VERSION_2, /* v2 channel */
IocpCloseProc, /* Close proc. */
IocpInputProc, /* Input proc. */
IocpOutputProc, /* Output proc. */
NULL, /* Seek proc. */
IocpSetOptionProc, /* Set option proc. */
IocpGetOptionProc, /* Get option proc. */
IocpWatchProc, /* Set up notifier to watch this channel. */
IocpGetHandleProc, /* Get an OS handle from channel. */
NULL, /* close2proc. */
IocpBlockProc, /* Set socket into (non-)blocking mode. */
NULL, /* flush proc. */
NULL, /* handler proc. */
-> /*IocpCutProc, /* cut proc. */
-> /*IocpSpliceProc, /* splice proc. */

static void
IocpCutProc (ClientData instanceData)
SocketInfo *infoPtr = (SocketInfo *) instanceData;

/* Unable to turn off reading, therefore don't notify
* anyone during the move. */
infoPtr->tsdHome = NULL;

static void
IocpSpliceProc (ClientData instanceData)
ThreadSpecificData *tsdPtr = TCL_TSD_INIT(&dataKey);
SocketInfo *infoPtr = (SocketInfo *) instanceData;

infoPtr->tsdHome = tsdPtr;

When a file event happens on the socket, the driver needs to alert the
notifier so the event source is called and the mask of the event is
handled. When a channel changes threads, the driver needs to know about
it, so the proper notifier thread can be awakened else it alerts to the
wrong notifier.. what good is that?

The feature of a Tcl_DriverCutProc and Tcl_DriverSpliceProc does not exist.
Maybe someday it will happen. I've already brought up the need for it and
can do no more short of forcing a patch down the core teams throats... As
waits are a persistent concept on windows as opposed to select() being per
wait, the bug in the channel system is obvious... IOW, foreach
Tcl_EventSetupProc call, WSAAsyncSelect doesn't need to be called on each
socket. It only needs to be set once. In my case, it is
CreateIoCompletionPort, which like WSAAsyncSelect, is only called once per
socket not per wait, unlike select which gets its fdsets filled foreach
wait. See the bug? It's even more plain to me with CreateIoCompletionPort
because I only use a single worker thread no matter how many threaded
interps Tcl may be running. Resetting the interest mask won't move the
notifier thread datum for me either (WSAAsyncSelect's hwnd param determines
where it returns), as the design of IOCP is upside down to how one normally
views asynchronous I/O.

Yes, I'm frustrated.. can you tell?
David Gravereaux < XXXX@XXXXX.COM >
[species: human; planet: earth,milkyway(western spiral arm),alpha sector]