[Qt-interest] BlockingQueuedConnection where and how to ?!

[BRM]

I would highly suggest you look at what the worker thread is actually receiving, and I suspect you are doing something quite dangerous with your signal.
The selection you do gets a list of pointers to items in the GUI. This is likely causing your crash as operations on the GUI (add/remove/move/etc.) will change the contents of the list without notifying the worker thread.

I'd highly suggest storing the actual data in a thread sharable container that is linked to the GUI for display purposes only; but can be accessed by the worker threads safely.
This gives you control of how the data is added/removed/etc - and by making your container a QObject derived class, you could even take advantage of signals/slots for each stored item
so worker threads could (a) use a thread sharable container to access - e.g. QSharedPointer - and (b) be notified of changes in the data.

Even making your list a list of QPointers would be of benefit since that at least gets notified when the pointer goes away; but you'll still need to convert to a thread sharable container for the data.

$0.02

Ben



----- Original Message ----
From: Mihail Naydenov <mlists at ymail.com>
To: Ender EREL <erelender at yahoo.com>; qt-interest at trolltech.com
Sent: Wed, December 2, 2009 12:07:42 PM
Subject: Re: [Qt-interest] BlockingQueuedConnection where and how to ?!

Im have attached a small and (not so) simple test.

It creates a list of 1000 list items, then randomly selects some of them.
The selected items are send to a worker, living, indeed on diff thread.
In a signal handler, the worker, starts a concurrent mapped work on the list.
The work itself is fake (just the stupid for loop)
Thats it. No explicit synchronization is need, because no data is accessed, just the Qt signal slot machinery.

Now, if the slot is connected non blocking the app crashes (randomly, but within a minute or two)

I dont see the clear reason for the crash, and at first I thought it was a QtConcurrent bug (disappears if I don't get the result back!)

Anyway, I am interested in opinions if it is possible to avoid the blocking, and why its is needed in such simple scenario.

Thank You
MihailNaydenov

P.S. Note that if I remove the worker class and implement its job also in the list class, again using signals and slots, but with explicit QueuedConnection,
the app also crashes! This is, without having a second object in a diff thead, just one object and QueuedConnection for the slots.



Original Message ----
> From: Ender EREL <erelender at yahoo.com>
> To: qt-interest at trolltech.com
> Sent: Wed, December 2, 2009 5:54:36 PM
> Subject: Re: [Qt-interest] BlockingQueuedConnection where and how to ?!
> 
> I think instead of avoiding the crash, you should dig deeper, find what 
> causes it and resolve the issue.
> 
> In my opinion, BlockingQueuedConnection makes sense when your signal is 
> connected to a slot of an object living in another thread but you need 
> the signalling thread to continue only after the slot is delivered. This 
> need may arise when a syncronisation is required somehow.
> 
> -- 
> Ender EREL
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest