0

So far in my journey to understanding threading in PySide/PyQT I've used Signals a bit to communicate between threads, but as far as I can tell signals don't let you return data (which makes sense, it's an asynchronous thing.)

I'm in a weird situation where I would love to run a method in another thread, but occasionally call back to the main thread to run UI interacting methods, such as getting the value from a QLineEdit.

Is there any way to call and get the result of a method in the main thread, and block the the current thread until we get that result?

Essentially, is it possible at all to do text = myWidget.text() from a separate thread?

Austin Witherspoon
  • 91
  • 2
  • 9
  • 1
    As also pointed out in a comment of the duplicated question, when this kind of requests are done, it's generally due to wrong implementation or misconception about thread usage (if not even misuse, as there are many occasions for which they're used while they shouldn't). So, the real question is: why do you need to "occasionally" access the UI thread? A thread should theoretically work on its own, it should even possibly exist without "knowing" absolutely nothing about any other thread. – musicamante Jun 03 '21 at 23:11
  • Yeah, I get that it's not the 'proper' way to do it, we're trying to make an extremely minimal wrapper around pyQt for inexperienced TDs at a VFX company to make simple UI apps that may do things like request data from an API, and we don't want to freeze the UI during that. We were trying to see if we could allow them to write single method callbacks that _mostly_ work in another thread to not lock the UI, but when certain methods are called can 'reach back' to the main thread to get/set data when needed. – Austin Witherspoon Jun 03 '21 at 23:20
  • Unfortunately the description is a bit vague, so it's really hard to give a complete answer. Depending on the situation you might need to choose different approaches (including avoiding threads at all). A possible idea could be to emit a signal whenever some "input" is required, and use a Queue or a simple empty value in a while loop waiting for a valid value value, but you should be *very* careful with that, as due to the asynchronous nature of multithreading you might risk unexpected behavior, bugs or crashes. Another possibility would be to "break" computations in smaller tasks, and use -> – musicamante Jun 03 '21 at 23:26
  • -> multiple "serial" threads that are created/started whenever the previous has been completed (again, through signals): start the first, do the computation, emit a signal with the partial result, which will then create/start the new thread with the received results and the "new" UI data. But, then again, this is just speculative. From what you're describing, it's also possible that using threads is actually not a correct path, or, at least, UI shouldn't allow interaction in the meantime. – musicamante Jun 03 '21 at 23:29

0 Answers0