Thiago Macieira wrote:
> We're not claiming that you have no problem. We're saying the problem is > probably in your own code. It's a kind of chicken-or-egg question. I'm indeed doing something that triggers a problem which is clearly deep inside Qt code. What I want to know is whether it's acceptable/foreseeable that that problem gets triggered or if it shouldn't be triggered. For now I'm going to take away the conclusion that the mutex indeed has to be in my code. > In the Qt documentation (and most other sane docu) "reentrant" means the > class can be used on different threads, but each instance must be > restricted to a single thread. So I didn't entirely mix up reentrant and thread-safe after all. I may end up trying to write a demonstrator after all to see if I can reproduce the lock-ups on Mac with a minimal example. > you ensured that the instance was only used by one instance at a time. Probably even more than that: only a single QFSW instance used at any given moment. How does QFSW handle a situation in which an already watched directory is changed while another directory is being added? Would something else happen when adding directories happens on a background thread while change signals are connected to slots on the main thread? > Another way is to explicitly use Qt::QueuedConnection to feed the QFSW A signal from the background dir reader thread connected to a slot on the main thread? That could be an interesting alternative to investigate indeed. R. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
