OriginalBugID: 1326 Bug
OS: Windows NT
3/1/99 various files in the "win" directory
Start two threads which create server sockets, the try to connect to the
Client and server hang.
First problem below, sockets not thread safe, has been fixed and confirmed. New test case in socket.test (socket-13.1) to check for it. 03/24/1999 16:37 - redman
Second problem not fixed yet, requires changes to allow multiple threads to own the same file channels without killing each other. 03/24/1999 16:37 - redman
03/26/1999 16:42 - redman - Second problem fixed, don't destroy standard handles during shutdown of threads.
The first thread through the windows socket code sets up a hidden window
for use in processing window messages. The socket code then expects that
the thread which calls WSAAsyncSelect will get the message. This is
clear from the fact that the function that gets the window socket
message (tclWinSock.c:SocketProc) looks in its own thread local storage
to search for sockets that have select data.
This is wrong. Only the thread which created the window will receive the
for the window, so no other thread will ever detect socket read_ready.
I hacked a change to create a global list containing references to the
structures, correlated with thread ids. In my codewhen SocketProc gets
(still always in "thread 1",the first thread through the socket code),
it searches the global structure for sockets to check.
Then in SocketCheckProc, I use this global list again to see if any
an event. If one does, and the socket is owned by the current thread, I
existing code path. If not, I explicitly queue the event for the thread
does own the socket, "thread 2", and then call Tcl_ThreadAlert.
I note that Tcl_ThreadAlert seems to think that each thread has a
it sends a message to the window referenced by the thread's thread
pointer, but all threads have the same value for this handle. I don't
think this will work either.
Somehow, the new event does get noticed in "thread 2" in my modified
the accept processing takes place as you would expect. However, after
is processed, "thread 2" ends up calling GetMessage, which blocks
I also noted (different bug) that if you start a thread, and it calls
it creates its own set of console input and output threads, even though
"main" thread already had a pair. When the new thread exits for any
the console reader thread created by the main thread gets a "BAD FILE"
and the process exits.
These kind of fundamental errors lead me to ask, has anyone performed
non-trivial testing of thread support on NT?
Hoping your answer is "yes, and we've fixed many bugs, but the fixes are
in the net cvs repository yet", I ask further, when am I likely to be
get a version that actually works, even mostly?