Daniel

Yes you are correct--I still would like to keep the crates distinct...I think it helps people consider including the decompressor as its own thing. If you want to build up...

wow so cool! It seems to be loaded now! Thanks for the help! I'm using the OPT because I do want to see the features together, especially all the img2img-related...

This is not a qasync bug. I was able to reproduce it on linux by pattern matching what Qasync was doing ```python import threading import time from PyQt6.QtCore import QMutex,...

The stack trace is ``` Thread 3 "python" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff31fe6c0 (LWP 340823)] Downloading source file /usr/src/python3.12-3.12.3-1ubuntu0.7/build-static/../Objects/weakrefobject.c clear_weakref (self=0x7ffff7398e30) at ../Objects/weakrefobject.c:60 warning: 60 ../Objects/weakrefobject.c:...

Possibly this sequence of events: ``` Thread 1 Thread 2 -------- -------- with QMutexLocker(mutex): with QMutexLocker(mutex): # Creates C++ QMutexLocker # Creates C++ QMutexLocker # Increments wrapper refcount # Race...

I have a much smaller repro case: ``` import threading from PyQt6.QtCore import QMutex, QMutexLocker, QCoreApplication import sys import faulthandler faulthandler.enable() app = QCoreApplication(sys.argv) mutex = QMutex() def worker(): for...

You can import this file at the beginning of your main and it should fix the problem by patching in native python threading.Lock() instead of using PyQt6's broken lock. [pyqt6_mutex_patch.py](https://github.com/user-attachments/files/21810899/pyqt6_mutex_patch.py)

Perhaps developers of qasync can consider patching this in until Riverbank Computing fixes PyQt6 or avoiding the QMutexLocker by merging https://github.com/danielrh/qasync/commit/b497a153378bc948458574e3f595711c49347f31