Re: [Development] codereview website down?
Am 01.10.2017 um 08:37 schrieb Christian Gagneraud: https://codereview.qt-project.org is not loading, it hangs. Is it just for me? Hi Chris, I was just about asking the same question ;) " Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /. Reason: Error reading from remote server " Andre Chris ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] codereview website down?
https://codereview.qt-project.org is not loading, it hangs. Is it just for me? Chris ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Should QFileSystemWatcher be thread-safe? (Qt 5.8.0)
Hi, On Saturday 30 September 2017 16:24:57 René J. V. Bertin wrote: > Konrad Rosenbaum wrote: > > Apart from this I'd suspect you will still get the SEGV if you do not > > block - even if the frequency changes. > > As in when emitting the signal too frequently from multiple threads? No. as in how many times out of the total signals delivered it actually crashes. When dealing with threads and signals between them determinism flies out the window and the tiniest change in timing can change behavior radically. > For my personal education, what happens behind the scenes when a signal is > sent from one thread to a slot in a different thread? Whenever a QueuedConnection triggers the sending object generates an event and delivers it to the event queue of the thread that owns the target slot's object. Whenever that thread's event loop is called again it will start to work on those events > Can I assume > there's some kind of fifo that ensures signals are delivered in order of Never assume order. > being sent and such that producer and consumer don't try to modify > (access) the queue concurrently? Kind of. The receiving end of the event queue is of course programmed in a thread safe way. And new events are usually queued towards the end of that queue. BUT. There are complications: for one, and this cannot be stressed enough, if you are dealing with threads you cannot assume anything to be completely deterministic or in order. Threads execute in a (seemingly) random order and can interrupt or race each other. For another: some events are more important or less important than others - e.g. the deleteLater event is normally only handled at the top level of the event loop to prevent crashes caused by less then absolutely ingenious programmers using QueuedConnection, deleteLater and QEventLoop (that fact saved my bacon a few times). So, the order of events is not 100% guaranteed. Most of the time events will be received and handled in the order they were sent, but there are exceptions. Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Should QFileSystemWatcher be thread-safe? (Qt 5.8.0)
Simon just gave a talk about signals and slots on different threads and the internals of how Qt handles this at CppCon in Seattle yesterday. I would suggest you have a look at the video of his presentation when it comes out. You could also look at the documentation: http://doc.qt.io/qt-5/threads-qobject.html with particular attention to "Signals and Slots Across Threads" On 09/30/2017 10:24 AM, René J. V. Bertin wrote: Konrad Rosenbaum wrote: Apart from this I'd suspect you will still get the SEGV if you do not block - even if the frequency changes. As in when emitting the signal too frequently from multiple threads? For my personal education, what happens behind the scenes when a signal is sent from one thread to a slot in a different thread? Can I assume there's some kind of fifo that ensures signals are delivered in order of being sent and such that producer and consumer don't try to modify (access) the queue concurrently? R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Should QFileSystemWatcher be thread-safe? (Qt 5.8.0)
Konrad Rosenbaum wrote: > Apart from this I'd suspect you will still get the SEGV if you do not block > - even if the frequency changes. As in when emitting the signal too frequently from multiple threads? For my personal education, what happens behind the scenes when a signal is sent from one thread to a slot in a different thread? Can I assume there's some kind of fifo that ensures signals are delivered in order of being sent and such that producer and consumer don't try to modify (access) the queue concurrently? R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Should QFileSystemWatcher be thread-safe? (Qt 5.8.0)
Konrad Rosenbaum wrote: > You do know what a thread is - right? ;-) Yeah, my momma taught me long ago ;) > Sorry, I'm too lazy/busy to read the source right now to make sure that no > signal handlers are used here. No problem, it was just curiosity. > Apart from this I'd suspect you will still get the SEGV if you do not block > - even if the frequency changes. This points to you using some kind of > pointer that is not properly controlled (e.g. sending a signal to a QFSW > that is already deleted). I think it was false alarm. I used a lambda expression as slot and must have misunderstood why the other lambdas in the same function can use '[&]' without ending up with invalid references in the body. I only need the watcher instance, so I'm just passing the reference to it explicitly. No more crashing and less ambiguous anyway :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Should QFileSystemWatcher be thread-safe? (Qt 5.8.0)
On Saturday 30 September 2017 11:31:13 René J. V. Bertin wrote: > Thiago Macieira wrote: [about internal mutex] > > You cannot, because neither the kqueue, inotify or poll backends do > > that. > > Those three have no mutexes at all. You have to block the event loop of > > the thread they were created on. > > That all applies to multithreaded usage, right? What happens when a change > is signalled while an item is being added *on the same thread*? At least > the kqueue and inotify backends are written around an API that sends > asynchronous notifications, no? You do know what a thread is - right? ;-) A quick google search tells me that inotify and kqueue work by signaling file events through the normal mechanism of the event loop. This means the change is appended to the event queue and handled the next time this thread is idle or explicitly calls the event loop. It is impossible for the change event to interrupt the add method or vice versa. The only mechanism that can do this in the same thread is a signal handler. Sorry, I'm too lazy/busy to read the source right now to make sure that no signal handlers are used here. > I'm now investigating the idea of sending a signal from the dirlister > thread, connected to a slot in the main thread with Qt::QueuedConnection > . After some initial success I'm now getting a SEGV that I don't yet > understand. I'm beginning to wonder if one shouldn't use a blocking > QueuedConnection... BlockingQueuedConnections should only be used if you really need the result, there is no asynchronous way of transmitting the result and you can make sure that there will not be a deadlock. Apart from this I'd suspect you will still get the SEGV if you do not block - even if the frequency changes. This points to you using some kind of pointer that is not properly controlled (e.g. sending a signal to a QFSW that is already deleted). Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Should QFileSystemWatcher be thread-safe? (Qt 5.8.0)
Thiago Macieira wrote: >> >> How does QFSW handle a situation in which an already watched directory is >> >> changed while another directory is being added? SNIP >> > >> > 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)? > > You cannot, because neither the kqueue, inotify or poll backends do that. > Those three have no mutexes at all. You have to block the event loop of the > thread they were created on. That all applies to multithreaded usage, right? What happens when a change is signalled while an item is being added *on the same thread*? At least the kqueue and inotify backends are written around an API that sends asynchronous notifications, no? I'm now investigating the idea of sending a signal from the dirlister thread, connected to a slot in the main thread with Qt::QueuedConnection . After some initial success I'm now getting a SEGV that I don't yet understand. I'm beginning to wonder if one shouldn't use a blocking QueuedConnection... R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
