threads and socket question

  • Thread starter Gonçalo Rodrigues
  • Start date
G

Gonçalo Rodrigues

Hi,

My setup is the following: I have socket s from which I want to read
and write. So I made the following set up:

There is a thread whose only job is to read. Any data read (from recv
call) is just passed to (some) Queue. This thread is "owned" by a
second thread waiting on a Queue for write requests. The thread just
pops these from the Queue, and calls the send method from the socket.
This thread also takes care of closing the socket or (possibly)
handling any exceptions raised due to socket operation.

So my question is: since I have two threads sharing the same socket,
even though one is only reading and the other does everything else, do
I have to watch out for any "concurrency" issues?

P.S: This is for learning experience. So it's of no use telling me
that I should learn Twisted :) I may (eventually) get there, but at
the moment I feel more omfortable with working with plain blocking
sockets.

With my best regards,
G. Rodrigues
 
D

Daniel T.

Gon?alo Rodrigues said:
My setup is the following: I have socket s from which I want to read
and write. So I made the following set up:

There is a thread whose only job is to read. Any data read (from recv
call) is just passed to (some) Queue. This thread is "owned" by a
second thread waiting on a Queue for write requests. The thread just
pops these from the Queue, and calls the send method from the socket.
This thread also takes care of closing the socket or (possibly)
handling any exceptions raised due to socket operation.

So my question is: since I have two threads sharing the same socket,
even though one is only reading and the other does everything else, do
I have to watch out for any "concurrency" issues?

P.S: This is for learning experience. So it's of no use telling me
that I should learn Twisted :) I may (eventually) get there, but at
the moment I feel more omfortable with working with plain blocking
sockets.

The first problem I can think of is the one that stopped me. Note the
code below... You can't close a blocked socket in python even from a
separate thread.

import unittest
import socket
import threading
import time

class SocketAcceptor ( threading.Thread ):
def __init__( self, socket ):
threading.Thread.__init__( self )
self.socket = socket
self.done = 0

def run( self ):
self.socket.bind( ( "", 3424 ) )
self.socket.listen( 5 )
try:
child, ip = self.socket.accept()
except:
pass
self.done = 1

class SocketTester ( unittest.TestCase ):
def testClose( self ):
ss = socket.socket()
acceptor_thread = SocketAcceptor( ss )
acceptor_thread.start()
time.sleep( 1 )
ss.close()
time.sleep( 1 )
self.assertEquals( acceptor_thread.done, 1 )

if __name__ == '__main__':
unittest.main()
 
G

Gonçalo Rodrigues

The first problem I can think of is the one that stopped me. Note the
code below... You can't close a blocked socket in python even from a
separate thread.

Thanks for this piece of info. My experiences with my setup confirm
it.

I really want to keep the socket-closing in the write thread so my
problem is reduced to be able to order to read thread to die. What I
chose to do is to have it periodically check some exit flag to know
when to exit. I believe this can be done by calling select with a
timeout before the recv blocking call. Back to the docs and
Python-experimenting-mode.

With my best regards,
G. Rodrigues
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,763
Messages
2,569,562
Members
45,039
Latest member
CasimiraVa

Latest Threads

Top