Operating system suspend/wake up - thread stall

Hello there, mates!

I have a multi-threaded app with threads waiting on a queue events and then handling them.
The processing is like

class MyThreadClass(Thread):
    def __init__(self, account, notificationQueue, commandQueue):
        super().__init__(name='MyThreadClass', daemon=True)

    def run(self) -> None:
        while True:
            queueData = self.commandQueue.get(block=True, timeout=None)
            self.doSomething(queueData)
            pass

   def doSomething(data)
      print('debug 1')
      # some other code
      print('debug 2')
      # some other code
      print('debug 3')
      # some other code


### The threads are started something like
   threadClass = MyThreadClass()
   threadClass.start()

I observe that when I have a thread’s subroutine doSomething running if I suspend the operating system then it sticks at one of the debug statements and then nothing happens after i wake up the system.
Even though the messages are coming to the ‘commandQueue’ the thread never seems to get control back from the ‘doSomething’ subroutine which is ‘stuck’ when the operating system is suspended.

Am I missing something in the way I configure/start the threads?
Or maybe I should be handling operating system suspend events?

Any suggestions?

P.S. Sorry about the way I name variables. It’s coming from Java style.

Hi Dmitry,

You have asked a very interesting question. I am not an expert in
threading, but in my ignorance it sounds like it might be a bug in
Python’s threading implementation.

Can you tell us what version of Python, and what OS, you are using?

If you can replicate this on more than one version and/or OS, that would
be good to know too.

This seems likely to be a tricky question to get a good answer for, so
you might like to post it on the Python-List mailing list as well:

https://mail.python.org/mailman/listinfo/python-list

and perhaps Stackoverflow and Reddit

If you get an answer elsewhere, please post a link to the answer here.

Interesting problem. May depend on the operating system.

Does the same thing happen in a single-threaded program?

What is stdout connected to?

I’m going to assume that you elided the setting of self.commandQueue from the example, otherwise this wouldn’t work at all. How many threads are reading from the same queue? How many of them are blocking on the thread at the time you suspend the system?

@steven.daprano
I’m using Xubuntu 20.04.3 LTS w/Python 3.8.10.

@Rosuav
I don’t know about single-threaded app. No test but I can try to devise one.
stdout is just terminal (I’m running my app from the console).

The app has multiple threads each having its own ‘command’ queue to which a ‘main’ thread posts messages.

Actually, I thought about it a bit more.
May be it’s not Python threading per se, but the corresponding libraries I’m using.
The doSomething has 2 implementations to retrieve email information. One implementation is using poplib, the other is using selenium (webmail scraping).
In both cases if there’s a call to either poplib or selenium when the system is suspended when it wakes up the corresponding thread seems to be stuck.

Maybe I actually need to ask developers of those libraries about OS ‘suspend/wake-up’ behavior?
First I experienced it with poplib only. When I added selenium implementation I noticed the same ‘thread stuck’ behavior.
I know about it simply because I don’t see the doSomething full list of debug output messages in the console. The subroutine seems to just be stuck in the middle.

Selenium seems like a prime target here. Web browsers often have their own behaviour on suspend/resume. This seems far more likely a culprit than threading itself.

@Rosuav
I would guess, yes.
But also looks like poplib is not w/o deficiencies in that regard.

I will close this discussion and try to ask somewhere else.

Thanks, anyway.