window freezed

[jrodway]

Ok,

I've read the complete project and this method is called from 2 differents callback methods from two different objects.

¿Is it possible that i need a mutex in the method shared by the 2 callbacks?

(sorry for my mistake at explain my problem)

[wysota]

You don't need any mutexes if your program does not have more than one thread. So far we have seen no evidence of more than one thread in your program.

[jrodway]

I'm not sure but each callback method i think, generates a thread because it's possible to receive the two different messages at the same time.

If this two callback methods, use the method that writes in the textfields, i think i need to use a mutex to prevent...

Am i in an error?

[wysota]

I'm not sure but each callback method i think, generates a thread because it's possible to receive the two different messages at the same time.

I don't know what is the origin of those callbacks but if this is purely Qt code, then there are no threads involved. If there are threads involved, then you can't call any UI-related code from within those callbacks.

[d_stranz]

I'm not sure but each callback method i think, generates a thread because it's possible to receive the two different messages at the same time.

Signals and slots within the GUI do not use threads. I don't think you really understand what "thread" means. In the Qt GUI, everything is queued, and events (including slots) are executed in a sequence. It is impossible for two "messages" (whatever those are) to be received at the same time. One will be received and put into the event queue first, followed by the second one, and the code for them will be executed in the order they were put into the queue.

The handlers for some events (like paintEvent()) will execute the event only once and remove extra copies from the queue to avoid unnecessary processing, but in general things in the event queue are executed in first-in, first-out order.

[jrodway]

I'm sorry, but i use only qt code with the ui. The rest of the application use Threads posix.

I've got two threads in the main application that try to modify the textfields of the ui. is it possible that i need a mutex to avoid the freeze of the window?

Thanks for your opinions.

[wysota]

I've got two threads in the main application that try to modify the textfields of the ui. is it possible that i need a mutex to avoid the freeze of the window?

No, you cannot access any QObject from any thread other than the thread it belongs to (meaning the application thread in case of Qt widgets) and there is no way to work around this using mutexes. If there are threads involved, you need to change your application design so that those extra threads post messages to the UI thread and then the UI thread modifies state of the wigdets.

[anda_skoa]

I think the signal/slot connection in the code above should take care of crossing the thread boundary properly, i.e. it should become a Qt::QueuedConnection.
But you can try to specify that explictly as the fifth argument to connect().

Independently I would strongly recommend to make the char* -> QString conversion somewhere before emitting the signal, so that the thread which created the array can delete it as well.

And, as mentioned earlier, it should do that using the correct delete operator.

Cheers,
_