#710 Thread logic for sockets incorrect on NT

obsolete: 8.1b1
closed-fixed
nobody
2
2001-03-31
2000-10-26
Anonymous
No

OriginalBugID: 1326 Bug
Version: 8.1b1
SubmitDate: '1999-03-02'
LastModified: '1999-03-26'
Severity: CRIT
Status: Released
Submitter: pat
ChangedBy: redman
OS: Windows NT
Machine: X86
FixedDate: '1999-03-26'
ClosedDate: '2000-10-25'

Name:
Dennis Parker

CVS:
3/1/99 various files in the "win" directory

Extensions:
none

ReproducibleScript:
Start two threads which create server sockets, the try to connect to the
second one.

ObservedBehavior:
Client and server hang.

DesiredBehavior:
No hanging

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
message
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
socket
structures, correlated with thread ids. In my codewhen SocketProc gets
called,
(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
socket needs
an event. If one does, and the socket is owned by the current thread, I
use the
existing code path. If not, I explicitly queue the event for the thread
that
does own the socket, "thread 2", and then call Tcl_ThreadAlert.

I note that Tcl_ThreadAlert seems to think that each thread has a
window, since
it sends a message to the window referenced by the thread's thread
specific
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
code, and
the accept processing takes place as you would expect. However, after
the event
is processed, "thread 2" ends up calling GetMessage, which blocks
forever.

I also noted (different bug) that if you start a thread, and it calls
"puts",
it creates its own set of console input and output threads, even though
the
"main" thread already had a pair. When the new thread exits for any
reason,
the console reader thread created by the main thread gets a "BAD FILE"
error
and the process exits.

These kind of fundamental errors lead me to ask, has anyone performed
any
non-trivial testing of thread support on NT?

Hoping your answer is "yes, and we've fixed many bugs, but the fixes are
not
in the net cvs repository yet", I ask further, when am I likely to be
able to
get a version that actually works, even mostly?

Discussion

  • Brent B. Welch

    Brent B. Welch - 2000-10-26
    • priority: 5 --> 2
    • status: open --> closed-fixed
     
  • Don Porter

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

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

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks