Hi, not sure if this would look funny (would it?), but may be referencing the stock documentation page at http://doc.qt.io/qt-5.9/threads-reentrancy.html could help avoid further confusion (and unnecessarily heating the thread).
On Sat, Sep 30, 2017 at 12:50 AM, <development-requ...@qt-project.org> wrote: > Send Development mailing list submissions to > development@qt-project.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.qt-project.org/mailman/listinfo/development > or, via email, send a message with subject or body 'help' to > development-requ...@qt-project.org > > You can reach the person managing the list at > development-ow...@qt-project.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Development digest..." > > > Today's Topics: > > 1. Should QFileSystemWatcher be thread-safe? (Qt 5.8.0) > (Ren? J.V. Bertin) > 2. Re: Should QFileSystemWatcher be thread-safe? (Qt 5.8.0) > (Konrad Rosenbaum) > 3. Re: Should QFileSystemWatcher be thread-safe? (Qt 5.8.0) > (Ren? J.V. Bertin) > 4. Re: Should QFileSystemWatcher be thread-safe? (Qt 5.8.0) > (Milian Wolff) > 5. Re: Should QFileSystemWatcher be thread-safe? (Qt 5.8.0) > (Thiago Macieira) > 6. Re: Should QFileSystemWatcher be thread-safe? (Qt 5.8.0) > (Thiago Macieira) > 7. Re: Should QFileSystemWatcher be thread-safe? (Qt 5.8.0) > (Ren? J. V. Bertin) > 8. Re: Should QFileSystemWatcher be thread-safe? (Qt 5.8.0) > (Thiago Macieira) > 9. Re: Should QFileSystemWatcher be thread-safe? (Qt 5.8.0) > (Ren? J. V. Bertin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 29 Sep 2017 11:35:40 +0200 > From: Ren? J.V. Bertin <rjvber...@gmail.com> > To: "'development@qt-project.org'" <development@qt-project.org> > Subject: [Development] Should QFileSystemWatcher be thread-safe? (Qt > 5.8.0) > Message-ID: <1811414.Bhil7bdXDD@bola> > Content-Type: text/plain; charset="us-ascii" > > Hi, > > I've been running into issues using adding and removing entries from QFSW > in concurrent threads. This is in KDevelop while adding all directories of > multiple projects (source trees) to a single QFSW instance per project. The > app is somewhat complex so I think but am not entirely certain that the > source trees are read on a single background thread; if I'm correct each > QFSW instance is fed from a single thread only. (The QFSW instances are > created and "slotted" on the main thread.) > > The issues range from more or less severe lock-ups on Mac (the hard > lock-ups occur in the FSEvents backend) to double-free crashes on Linux. I > can only avoid them by using a single mutex that ensures that only 1 thread > can use the class at a time. > > The QFSW documentation only mentions the class is reentrant. Is QFSW > supposed to be thread-safe (at least at the class level), on all platforms? > Or do we have to provide our own protection mechanisms if we want to use > the class this way? > > Thanks, > R. > > > ------------------------------ > > Message: 2 > Date: Fri, 29 Sep 2017 11:49:32 +0200 > From: "Konrad Rosenbaum" <kon...@silmor.de> > To: "'development@qt-project.org'" <development@qt-project.org> > Subject: Re: [Development] Should QFileSystemWatcher be thread-safe? > (Qt 5.8.0) > Message-ID: > <cf36d378c3d5fe6ecc72ec620771965b.squir...@squirrel.six.silmor.de> > Content-Type: text/plain;charset=iso-8859-1 > > Hi, > > On Fri, September 29, 2017 11:35, Ren? J.V. Bertin wrote: > > I've been running into issues using adding and removing entries from QFSW > > in concurrent threads. > [cut] > > The QFSW documentation only mentions the class is reentrant. Is QFSW > > supposed to be thread-safe (at least at the class level), on all > > platforms? Or do we have to provide our own protection mechanisms if we > > want to use the class this way? > > 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. You can have different instances on > different threads. > > Actually documenting it as "thread safe" would imply that even instances > can be shared across threads. This is much harder to implement for (I > believe) obvious reasons. > > This is why you were able to solve the problem with a Mutex: you ensured > that the instance was only used by one instance at a time. > > Another way is to explicitly use Qt::QueuedConnection to feed the QFSW or > to untangle your code to ensure each QSFW is only visible from one thread. > > > Konrad > > > > ------------------------------ > > Message: 3 > Date: Fri, 29 Sep 2017 14:54:53 +0200 > From: Ren? J.V. Bertin <rjvber...@gmail.com> > To: Milian Wolff <milian.wo...@kdab.com> > Cc: development@qt-project.org > Subject: Re: [Development] Should QFileSystemWatcher be thread-safe? > (Qt 5.8.0) > Message-ID: <1637195.QtcOVzZ2nT@portia.local> > Content-Type: text/plain; charset="us-ascii" > > On Friday September 29 2017 14:27:37 Milian Wolff wrote: > > > behavior you are supposedly seeing. > > So you still haven't bothered trying to reproduce this or prove me wrong, > aside implying I'm making this all up? In that case I'm not sure why *you* > come trolling on a post that intends to find out if QFSW is being used in a > way it's not supposed to be used - in which case there is no point in > wasting time with upstream demonstrators and patches. > > > > > ------------------------------ > > Message: 4 > Date: Fri, 29 Sep 2017 14:27:37 +0200 > From: Milian Wolff <milian.wo...@kdab.com> > To: development@qt-project.org > Cc: Ren? J.V. Bertin <rjvber...@gmail.com> > Subject: Re: [Development] Should QFileSystemWatcher be thread-safe? > (Qt 5.8.0) > Message-ID: <5125747.d2nQ8lOia2@agathebauer> > Content-Type: text/plain; charset="iso-8859-1" > > On Freitag, 29. September 2017 11:35:40 CEST Ren? J.V. Bertin wrote: > > Hi, > > > > I've been running into issues using adding and removing entries from > QFSW in > > concurrent threads. This is in KDevelop while adding all directories of > > multiple projects (source trees) to a single QFSW instance per project. > The > > app is somewhat complex so I think but am not entirely certain that the > > source trees are read on a single background thread; if I'm correct each > > QFSW instance is fed from a single thread only. (The QFSW instances are > > created and "slotted" on the main thread.) > > > > The issues range from more or less severe lock-ups on Mac (the hard > lock-ups > > occur in the FSEvents backend) to double-free crashes on Linux. I can > only > > avoid them by using a single mutex that ensures that only 1 thread can > use > > the class at a time. > > > > The QFSW documentation only mentions the class is reentrant. Is QFSW > > supposed to be thread-safe (at least at the class level), on all > platforms? > > Or do we have to provide our own protection mechanisms if we want to use > > the class this way? > > Please Rene, before you waste more time by getting yet more people > involved. > Build a MWE, i.e. a trivial single-file Qt application that exhibits the > behavior you are supposedly seeing. Then when you think you are sure what > is > going on we can talk. Don't put up open hypotheses on random channels - > it's > really draining everyones energy for no good gain. And don't come again > with > the "I don't have time" - it's less time to create a MWE than to write > dozens > of mails that then have no outcome. > > -- > Milian Wolff | milian.wo...@kdab.com | Senior Software Engineer > KDAB (Deutschland) GmbH&Co KG, a KDAB Group company > Tel: +49-30-521325470 > KDAB - The Qt Experts > > > > > ------------------------------ > > Message: 5 > Date: Fri, 29 Sep 2017 08:51:54 -0700 > From: Thiago Macieira <thiago.macie...@intel.com> > To: <development@qt-project.org> > Subject: Re: [Development] Should QFileSystemWatcher be thread-safe? > (Qt 5.8.0) > Message-ID: <2623428.N9ttvi6u71@tjmaciei-mobl1> > Content-Type: text/plain; charset="us-ascii" > > On sexta-feira, 29 de setembro de 2017 02:49:32 PDT Konrad Rosenbaum wrote: > > This is why you were able to solve the problem with a Mutex: you ensured > > that the instance was only used by one instance at a time. > > That is not a full solution. You may be able to serialise all *your* access > with a mutex, but since QFSW is doing some form of I/O, it may still be > woken > up by another thread and do work there. You need to block that thread's > event > loop (and you need to know which thread that is yourself) if you want to > ensure full serialisation. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > ------------------------------ > > Message: 6 > Date: Fri, 29 Sep 2017 08:52:45 -0700 > From: Thiago Macieira <thiago.macie...@intel.com> > To: <development@qt-project.org> > Subject: Re: [Development] Should QFileSystemWatcher be thread-safe? > (Qt 5.8.0) > Message-ID: <7177843.JS2enr4j1R@tjmaciei-mobl1> > Content-Type: text/plain; charset="iso-8859-1" > > On sexta-feira, 29 de setembro de 2017 05:54:53 PDT Ren? J.V. Bertin wrote: > > On Friday September 29 2017 14:27:37 Milian Wolff wrote: > > > behavior you are supposedly seeing. > > > > So you still haven't bothered trying to reproduce this or prove me wrong, > > aside implying I'm making this all up? In that case I'm not sure why > *you* > > come trolling on a post that intends to find out if QFSW is being used > in a > > way it's not supposed to be used - in which case there is no point in > > wasting time with upstream demonstrators and patches. > > We're not claiming that you have no problem. We're saying the problem is > probably in your own code. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > ------------------------------ > > Message: 7 > Date: Fri, 29 Sep 2017 21:50:07 +0200 > From: Ren? J. V. Bertin <rjvber...@gmail.com> > To: development@qt-project.org > Subject: Re: [Development] Should QFileSystemWatcher be thread-safe? > (Qt 5.8.0) > Message-ID: <6416392.OqD2sMKAdo@patux.local> > Content-Type: text/plain; charset="ISO-8859-1" > > 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. > > > > ------------------------------ > > Message: 8 > Date: Fri, 29 Sep 2017 13:09:41 -0700 > From: Thiago Macieira <thiago.macie...@intel.com> > To: <development@qt-project.org> > Subject: Re: [Development] Should QFileSystemWatcher be thread-safe? > (Qt 5.8.0) > Message-ID: <3989100.DsVr9K6CMQ@tjmaciei-mobl1> > Content-Type: text/plain; charset="iso-8859-1" > > On sexta-feira, 29 de setembro de 2017 12:50:07 PDT Ren? J. V. Bertin > wrote: > > 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. > > Even then we won't support you. QFSW, like almost all QObjects, must only > be > touched by one thread. Anything else you do is at your own risk. > > > 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? > > The Darwin implementation has an internal mutex so that the dispatcher > thread > (I'm assuming) is able to get to the current state. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > ------------------------------ > > Message: 9 > Date: Fri, 29 Sep 2017 23:47:29 +0200 > From: Ren? J. V. Bertin <rjvber...@gmail.com> > To: development@qt-project.org > Subject: Re: [Development] Should QFileSystemWatcher be thread-safe? > (Qt 5.8.0) > Message-ID: <1775543.FOxzUkLYz6@portia.local> > Content-Type: text/plain; charset="ISO-8859-1" > > Thiago Macieira wrote: > > >> 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? > > > > The Darwin implementation has an internal mutex so that the dispatcher > thread > > (I'm assuming) is able to get to the current state. > > Can I assume that the other platforms have a similar feature that blocks > access > to the current state while entries are being added or removed (and also > defers > adding/removing entries while sending out change notifications)? > > R > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > ------------------------------ > > End of Development Digest, Vol 72, Issue 38 > ******************************************* >
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development