Help needed in problem with Threads and sockets.

Gonçalo Rodrigues op73418 at mail.telepac.pt
Mon Dec 29 20:39:56 CET 2003


Hi,

I have a problem with threads and sockets. I'll try to describe the
problem in words with pseudo-code.

I've been working on a few classes to make it easier to work with
threads. This framework, let us call it that, consists in two parts.
The first part is just a basic thread class deriving from
threading.Thread with a few extra functionality that makes it easier
for a thread to spawn a new thread and "father it". Each of its
instances also has a queue.Queue where other threads can post data.
The other part is an Event class, whose instances are traded among
threads (via their queues). These Event classes also know how to
process themselves by calling a sequence of handlers and things are
made up in such a way that it's easy to add or remove handlers at
runtime.

In testing this framework, and also with a mind for future
applications, I tried to add sockets to the mix. 

The basic idea was that a socket was shared among two threads. The
*only* job of one of the threads is to listen to the socket and read
whatever is there, while the other socket listens to incoming requests
(in the form of Event's) like: open the socket, write to the socket,
close the socket, kill yourself, etc.

For a number of reasons, instead of dealing with sockets directly I
found it easier to deal with streams. So I just wrapped the socket in
a stream-like class. The stream class is little more than a thin
wrapper around socket.makefile(). In fact the whole thing is just:

class SocketProxy(object):

    def __init__(self, sockfile):
        super(SocketProxy, self).__init__(self)
        self._sockfile = sockfile

    def __getattr__(self, attrib):
        return getattr(self._sockfile, attrib)

    def write(self, s):
        self._sockfile.write(s)
        #Force a flush of the underlying socket.
        self._sockfile.flush()

And it's instantiated as SocketProxy(<some socket>.makefile()).

The structure run method of the read thread TReadStream is basically
(in pseudo-code and leaving out some gobbledigook dealing with
exception handling)

while self.exit:
    <select call with timeout>
    if <stream is readable>:
        data = <stream>.read()
        if data:
            <push data to parent thread>

The select calls with timeout are needed so that we can check the exit
flag and have the opportunity to kill the thread.

The run method of the write thread TWriteStream is basically:

<process a StartStreamEvent event>
try:
    while True:
        <pop an event from the queue>
        try:
            <process event>
        except Exception, e:
            <process error event>   
finally:
    <process an EndStreamEvent event>

Then there is a TStream(TWriteStream) whose only difference from
TWriteStream is in __init__  that instantiates a read thread
TReadStream and "fathers it" so that the read thread knows where to
push the data.

Now, all the tests for TReadStream and TWriteStream are passing which
means that their basic functionality is working OK. But in testing
TStream things fails miserably.

The test that fails is basically this:

<Write to the stream>
<Test that you read back is exactly what you sent.>

where the stream wraps a socket connected to an echo server => just
echoes back whatever it receives.

I added a few print statements here and there and the output I get is:

StartStreamEvent(None, priority = 1)
Select call.
WriteEvent('A test.', priority = 0)
Reading data.

This means that the following happened:

1. The thread started ok (StartStreamEvent processed). This means that
TStream was started and it's child threads (a TReadStream in this
case) started.
2. The read thread is about to make a select call.
3. A WriteEvent was processed (=> "A test." was sent to the stream).
4. The select call finished, the stream was readable and we're about
to read from the stream.

Then things hang up. The read call never finished, the data was not
pushed to the TStream, etc.

Anybody knows what might be the problem?

BTW, this is in Win2K. If you need more accurate descriptions (exact
code, etc.) just holler.

TIA, With my best regards,
G. Rodrigues




More information about the Python-list mailing list