| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 3 | |
On 23.01.08 23:19:53, Dimitri wrote: >> I will also try to look into your minimal example myself, time >> permitting... > > Here's proof that you should always try to strip down to a really *minimal* > example that reproduces the problem. > > I can reproduce the problem: > * without threads, > * without a custom class, > * without actually any signal argument. > This should give some clues... You or Dmitry stripped the example down too much. In the original, larger, example there is an event loop running the main thread - i.e. the one in which the receiver lives in. AFAIK there's no need for an event loop in the thread in which the emitting object lives. At least I know I don't have one in KDevelop code that does something similar. Andreas -- [ signature omitted ]
On Wed, Jan 23, 2008 at 11:58:28PM +0100, Andreas Pakulat wrote: > > You or Dmitry stripped the example down too much. In the original, > larger, example there is an event loop running the main thread - i.e. > the one in which the receiver lives in. AFAIK there's no need for an > event loop in the thread in which the emitting object lives. At least I > know I don't have one in KDevelop code that does something similar. > Hi, Andreas. Threads are not required to reproduce it. You can just force Qt to use Queued connection by specifying optional argument (Qt::QueuedConnection). I have no ideas, how to strip example any more :) -- [ signature omitted ]
Attachment:
signature.asc
Description: Digital signature
On 24.01.08 01:00:58, Dmitry Nezhevenko wrote: > On Wed, Jan 23, 2008 at 11:58:28PM +0100, Andreas Pakulat wrote: > > > > You or Dmitry stripped the example down too much. In the original, > > larger, example there is an event loop running the main thread - i.e. > > the one in which the receiver lives in. AFAIK there's no need for an > > event loop in the thread in which the emitting object lives. At least I > > know I don't have one in KDevelop code that does something similar. > > Hi, Andreas. > Threads are not required to reproduce it. You can just force Qt to use > Queued connection by specifying optional argument (Qt::QueuedConnection). In your example you don't start an event loop, thus Qt::QueuedConnection can't work as it relies on the event loop running. Andreas -- [ signature omitted ]
Andreas Pakulat wrote: >You or Dmitry stripped the example down too much. In the original, >larger, example there is an event loop running the main thread - i.e. >the one in which the receiver lives in. AFAIK there's no need for an >event loop in the thread in which the emitting object lives. At least I >know I don't have one in KDevelop code that does something similar. > >Andreas There *is* a bug. I ran Dmitry's code (not Dimitri's) and found out what it is. QMetaObject::activate() and QObject::~QObject() use the same non-recursive mutex to lock the object list. The problem is there is a call-out to user code in queued_activate with the mutex locked. That cannot happen: the mutex must be unlocked while calling out or deadlocks (such as the one in this thread) will happen. A minimal example would include a signal emission with a queued connection and with one parameter, whose constructor eventually calls QObject::~QObject (qDebug() does that because QTextStream has an internal QObject object). Please report to the task tracking system, so that it can be properly scheduled and tracked. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
On Sun, Jan 20, 2008 at 03:02:57PM +0100, Frank wrote:
>
> When I change the class to be a struct it works.
>
> What is the basic difference when using a struct or a class in SIGNALS ???
>
> class Data
> {
Have u called qRegisterMetaType<Data>("Data") ? There was no such line in
your example.
--
[ signature omitted ]
Attachment:
signature.asc
Description: Digital signature
Dmitry Nezhevenko wrote:
> On Sun, Jan 20, 2008 at 03:02:57PM +0100, Frank wrote:
>>
>> When I change the class to be a struct it works.
>>
>> What is the basic difference when using a struct or a class in SIGNALS
>> ???
>>
>> class Data
>> {
>
> Have u called qRegisterMetaType<Data>("Data") ? There was no such line in
> your example.
>
I did this in the main() function:
int main(int argc, char *argv[])
{
qInstallMsgHandler(myMessageOutput);
qRegisterMetaType< Data >("Data");
QApplication app(argc, argv);
MainWindow *window = new MainWindow;
window->show();
return app.exec();
}
Frank
--
[ signature omitted ]
On 20.01.08 18:03:51, Frank wrote:
> Dmitry Nezhevenko wrote:
>
> > On Sun, Jan 20, 2008 at 03:02:57PM +0100, Frank wrote:
> >>
> >> When I change the class to be a struct it works.
> >>
> >> What is the basic difference when using a struct or a class in SIGNALS
> >> ???
> >>
> >> class Data
> >> {
> >
> > Have u called qRegisterMetaType<Data>("Data") ? There was no such line in
> > your example.
> >
>
>
> I did this in the main() function:
Do you also use the Q_DECLARE_METATYPE macro for your custom data type?
Andreas
--
[ signature omitted ]
Hi Andreas!
From the Docs:
"Q_DECLARE_METATYPE ( Type )
This macro makes the type Type known to QMetaType. It is needed to use the
type Type as a custom type in QVariant.
Ideally, this macro should be placed below the declaration of the class or
struct. If that is not possible, it can be put in a private header file
which has to be included every time that type is used in a QVariant.
Adding a Q_DECLARE_METATYPE() makes the type known to all template based
functions, including QVariant. Note that if you intend to use the type in
queued signal and slot connections, you also have to call
qRegisterMetaType() since such connections are resolved at runtime."
For using the type in SIGNALS you do not have to use Q_DECLARE_METATYPE. Ok,
but I tried anyway putting it right after the class declaration. It does
not work. Same behaviour as if it was not there. The receiver slot is never
be called.
Thanks anyway!
Frank
Andreas Pakulat wrote:
> On 20.01.08 18:03:51, Frank wrote:
>> Dmitry Nezhevenko wrote:
>>
>> > On Sun, Jan 20, 2008 at 03:02:57PM +0100, Frank wrote:
>> >>
>> >> When I change the class to be a struct it works.
>> >>
>> >> What is the basic difference when using a struct or a class in SIGNALS
>> >> ???
>> >>
>> >> class Data
>> >> {
>> >
>> > Have u called qRegisterMetaType<Data>("Data") ? There was no such line
>> > in your example.
>> >
>>
>>
>> I did this in the main() function:
>
> Do you also use the Q_DECLARE_METATYPE macro for your custom data type?
>
> Andreas
>
--
[ signature omitted ]