Konrad Rosenbaum wrote:
>> And one cannot even rely on mutexes to "fix" or prevent that?
>
> If you use Mutexes right you can rely on them to serialize the code that
> blocks on the same Mutex, i.e. only one blocking code block is executed at
> the same time.
> Depending on hardware timings
On Mon, October 2, 2017 11:54, René J. V. Bertin wrote:
> Konrad Rosenbaum wrote:
>> 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
>
> So the sending object knows that the nature of
On Monday October 02 2017 11:12:35 Sergio Martins wrote:
Hi,
> You were probably capturing a local variable by reference inside the
> lambda, which then went out of scope.
That sounds likely (I used '[&]' as the other lambdas do in the same method. I
don't think I considered scope when trying
On 2017-09-30 13:54, René J. V. Bertin wrote:
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 Rosenbaum wrote:
Hi,
I see I'm not the only one accepting the fact that when dealing with event-
driven GUIs having a human-in-the-loop one rather quickly reaches a stage where
it becomes hard to guarantee anything (with all that implies for writing code
that handles unforeseen
On Saturday, 30 September 2017 02:31:13 PDT René J. V. Bertin wrote:
> > 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
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
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:
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
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
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
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
On sexta-feira, 29 de setembro de 2017 14:47:29 PDT René J. V. Bertin wrote:
> 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
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
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
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
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
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
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
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
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
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
22 matches
Mail list logo
