QTCP Socket Server and threads

[wysota]

I assure this by signaling to the proper thread. this is working right...

No, you don't assure anything. If you did, you wouldn't need mutexes. If you protect socket access by a mutex then it means that you expect more than one thread to access it.
The fact that you call a method from an object that is somehow associated with a thread, doesn't mean you call the method in the context of that thread.

So i am not getting any benefits from using threads here, but the amount of information being handle is very big. there is new values coming from serial ports (5) around 10 values/sec from each port that have to "deserialize", analyze and do specific actions.

Unless you have a really old machine, one thread is sufficient. If you have a really old machine, using more than one thread won't help if you have just a single CPU machine.

The gui displays this information assign it to specific widget and has to send it to the clients, when there is many clients connected, will the gui have a latency?

No, unless you have hundreds or thousands of high-traffic simultaneous connections (provided your network interface can cope with it). Currently you waste lot of time on locking and context switching without any benefits whatsoever.

[cafu1007]

No, you don't assure anything. If you did, you wouldn't need mutexes.

I use mutex if another thread try to access the CSocketPrivate class will emit a signal what will assure that the QTCPSocket functions are called in the thread that they have affinity...
maybe i dont need the usage of mutex for that, only with triggering the signal would be enough, or?

[wysota]

I use mutex if another thread try to access the CSocketPrivate class

You contradict yourself. Either only one thread accesses the data or not.

maybe i dont need the usage of mutex for that, only with triggering the signal would be enough, or?

You don't need threads. You're putting a lot of effort in trying to synchronize something that doesn't need synchronization. Just use signals and slots in one thread and it will work properly.

[cafu1007]

there is a public class(CSocket) and a private class(CSocketPrivate) if one want to send something have to go through the public class and if a this point the calling thread is not the one with the affinity a signal will be emitted,
i am not contradicting myself (I think ).

Well i have followed your the advice remove the threads, and mutex, is wroking good, Thanks.

[wysota]

there is a public class(CSocket) and a private class(CSocketPrivate) if one want to send something have to go through the public class and if a this point the calling thread is not the one with the affinity a signal will be emitted,
i am not contradicting myself (I think ).

Affinity of the signal doesn't matter. What matters is the context in which the socket is accessed.

I have one problem the client application is receiving very delayed what the server sends. Why? is it normal? how can i make the client to empty the buffer faster? the reading of the buffer is done using a timer with 50ms interval.

Hard for me to say without seeing the actual code. It might be that you're blocking execution of the thread with something (like a mutex or a blocking call to a device).

[cafu1007]

The problem of this solution without thread is if the main thread gets block because of re-sizing, moving the GUI or anything else that blocks the main thread, everything else will stop. And i need to know if a value from the one being reading from the serial port changes and its in a critical range to do an action according to this...

---

Added after 6 minutes:

Hard for me to say without seeing the actual code. It might be that you're blocking execution of the thread with something (like a mutex or a blocking call to a device).

There was stuff in the buffer but I was not making it empty properly.

[wysota]

The problem of this solution without thread is if the main thread gets block because of re-sizing, moving the GUI or anything else that blocks the main thread, everything else will stop.

The actions you mention do not block the thread.

And i need to know if a value from the one being reading from the serial port changes and its in a critical range to do an action according to this...

In that case using sockets is a bad idea at all. So is using a non-RT operating system. It can always happen that your application gets frozen by the operating system for a number of miliseconds. Threads will not help in any way here. Time critical conditions need real time operating systems. So it's either getting a real-time operating system or accepting that at times things can temporarily go out of control.

[cafu1007]

HI There, as i was recommended i am not using thread any where. Everything is running in a single thread (The main). but during debugging i see that at least 6 thread are created.

is the any Qt class that creates new thread silently?

[wysota]

is the any Qt class that creates new thread silently?

Yes, QFileSystemModel.

[ChrisW67]

Also QNetworkAccessManager for HTTP requests: http://blog.qt.digia.com/2011/04/29/...accessmanager/

[cafu1007]

HI There,

I was told that press down click event on the gui wil not stop the event loop.
I monitor what is send and received in the serial port. When i hold down the mouse over the title bar for moving the Windows, there is not receiving information (i would say not read) from the serial port, i used Qextserialport class for serial communication. is this a Qt problem, Qextserialport or simply a block on the event loop?

Thanks

[wysota]

This is somehow related to Windows display system. Qt has no influence on it since the title bar is not part of your application.