Databases
StackOverflow2013
Postsdbo
POPython threading design question (Working with a method that blocks forever)
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POPython threading design question (Working with a method that blocks forever)
    primarykey
    data
    text
    <p><strong>UPDATED POST</strong> So, I found a solution to what I was doing it is to use <a href="https://stackoverflow.com/questions/323972/is-there-any-way-to-kill-a-thread-in-python">Is there any way to kill a Thread in Python?</a></p> <p>I would like to get some validation on design. We have a fairly large system, and one components of the system is the communication component. It is in charge of two things, one sending messages, and two queuing any messages that get received (to file,db, queue, etc.) I am receiving the message via a provided library that basically can just wait forever for a message to arrive. </p> <p>Questions:</p> <p>1 ) Is it best to have One main thread, and two sub threads? </p> <p>2) Is it better to allow the Receive thread to just block forever until a message arrives? Or should I allow for it to timeout(which is an exception), and just continue to loop? </p> <p>Let me know whatever more information you may need.</p> <p>Right now I basically have a receive thread, and a main thread (which also handles the sending), which you can see below. The only thing not included below is the fect I can now call "terminate" on MessageReceiver and it will exit.</p> <hr> <p><strong>ORIGINAL POST</strong> I am trying to wrap a thread around some receiving logic in python. Basically we have an app, that will have a thread in the background polling for messages, the problem I ran into is that piece that actually pulls the messages waits forever for a message. Making it impossible to terminate... I ended up wrapping the pull in another thread, but I wanted to make sure there wasn't a better way to do it.</p> <p>Original code: </p> <pre><code>class Manager: def __init__(self): receiver = MessageReceiver() receiver.start() #do other stuff sending/etc... class MessageReceiver(Thread): receiver = Receiver() def __init__(self): Thread.__init__(self) def run(self): #stop is a flag that i use to stop the thread... while(not stopped ): #can never stop because pull below blocks message = receiver.pull() print "Message" + message </code></pre> <p>I know the obvious locking issues exist, but is this the appropriate way to control a receive thread that waits forever for a message?</p> <p>One thing I did notice was this thing eats 100% cpu while waiting for a message... **If you need to see the stopping logic please let me know and I will post.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USCommunity
    1. USNix
    plurals
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. COCould you please post the code for `Receiver`?
      singulars
      1. POPython threading design question (Working with a method that blocks forever)
      1. USTravis Mehlinger
    2. COto us the receiver is a black box, and basically takes 1 argument "timeout". As I said below, we want this thing to wait forever, unless we decide to close the program then we need a way to be able to stop the pull.
      singulars
      1. POPython threading design question (Working with a method that blocks forever)
      1. USNix
    3. COCan you tell us anything about `Receiver`? Do you know if `pull()` is CPU-bound or IO-bound? It's difficult to guess what the problem is without knowing anything about the apparent cause.
      singulars
      1. POPython threading design question (Working with a method that blocks forever)
      1. USTravis Mehlinger
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload