Bizarre bug with a slot

[hardgeus]

Well.. this code doesn't compile. It complains _sleep() is undefined. Anyway don't take it personal but sleeping in a slot is a really stupid idea And I can imagine some failsafe mechanism kicks in and emits a signal for the second time because of a timeout or something.

Regarding compilation, Note my earlier explanation that under Linux you have to remove the "_" from the sleep function and change the argument from microsectonds to seconds.

At any rate, the sleep is only there to reproduce the bug

In the actual code, I am taking the XML I received and inserting into a local SQLite database. The insert loop is taking about a minute or so, and that is where I run into this bug.

If I have an expensive operation to perform as the result of an HTTP request, where else can I execute my code other than in the callback slot? I really don't think re-firing the signal is desirable behavior from the signal/slot mechanism...Is this re-firing documented behavior?

[wysota]

At any rate, the sleep is only there to reproduce the bug

In the actual code, I am taking the XML I received and inserting into a local SQLite database. The insert loop is taking about a minute or so, and that is where I run into this bug.

So make it last a second or don't insert into the database as a reaction to a timer-based signal. Post an event or use a 0 timeout timer to trigger a deffered call.

If I have an expensive operation to perform as the result of an HTTP request, where else can I execute my code other than in the callback slot? I really don't think re-firing the signal is desirable behavior from the signal/slot mechanism...Is this re-firing documented behavior?

It's not the same signal. It might be a signal related to timing out something. Anyway I'm just guessing here. Move the query elsewhere and your problem will go away. Otherwise closely examine the second signal to see if it is a copy of the first one.