12
AlgoRythm
29d

Fucking hate Qt.

Spent all morning trying to figure out how their bullshit QThreadPool works with their bullshit QRunnable but after a bunch of bullshit asynchronous testing I figured that my thread object was being collected and deleted before I was done with it, for no reason. Now if the race condition was documented... This wouldn't be an issue. But every google search brought up nada. Eventually I resorted to turning off autoDelete on the runnable, but then I just have a memory leak, obviously.

I couldn't find a way to manually clean up a QRunnable in Python. What the fuck.

I just went back to good old fashioned QThreads... This is why I quit Qt in the first place.

Comments
  • 0
    All because QThread had a finished signal... But QRunnable has no way of determining when it's done! What the fuck? Why wouldn't a Runnable object have a way to determine completion? That's absolutely retarded.
  • 0
    Did you post on the Qt forums?

    I usually get good answers about difficult issues on there. I looked at the docs for QRunnable, they mention a potential for a race condition. But your issue sounds different.
  • 1
    @AlgoRythm It says on here:

    https://doc.qt.io/qt-5/...

    They get autodeleted when the last thread finishes. Are you expecting them to stick around for something? I am confused as to what is happening. If you have code I could test it.
  • 3
    @Demolishun it's collecting in the middle of the run function. It's being awfully retarded. I have my solution now, I just wanted to rant, not go back and re-open that wound.

    I was trying to emit a finished signal at the end of the run function. But it didn't get there before collection unless I printed out the QThread currentId or something similar.
  • 0
    @Demolishun it shows "reliability" factor of forums with new spectrum of confusion added each year. Mail lists square one?
  • 1
    @AlgoRythm Sounds like a bug then. Yeah, fuck Qt! lol Glad you solved it. I usually just use QThreads for things.
  • 0
    @Demolishun now just to deal with the fact that buttons with a corner radius don't react to click if you click on the border......

    Fucking issue after issue.
  • 0
    @vintprox I dont know what this means.
  • 0
    "Note that QThreadPool is a low-level class for managing threads, see the Qt Concurrent module for higher level alternatives."
  • 1
    @AlgoRythm This sounds like "borderline" insanity... I am so sorry, not sorry...
  • 1
    @AlgoRythm About the runnable part not knowing when it is finished

    Is it probably because it is an interface rather than an actual stateful implementation?

    Seems similar to how Java has threads that can wrap runnables, but runnables are just behavioural interfaces.

    Might just be talking shit here, I know zero Qt, so if I am just ignore me
  • 0
    @nekokatt

    "If autoDelete is enabled the QRunnable will be deleted when the last thread exits the run function."

    It should not have been deleted.
  • 0
    @nekokatt You're on the right track, but since their ThreadPool object takes runnables instead of threads, I can't execute something on another thread and return when it's done... which is the worst goddamn async design pattern I have ever fucking heard of......
  • 0
    strange, no clue sorry!

    although if it is a runnable, i assume it is a callable object or some kind of class they define. Can you not subclass that and place a threaded event or flag or something on the runnable object?
  • 1
    @AlgoRythm Sure you weren't using QDeadPool?
  • 1
    @Demolishun I can be rather sure because my issue was an early death, but QDeadPool can't die.
  • 1
    @AlgoRythm But I would expect QDeadPool to kill all the Runners.
  • 0
    @Demolishun I might have been looking at it the wrong way then
Add Comment