I still ask about thread synchronization

[rlebeau]

if instead of using a single global variable msg I would use two global variables

The only thing that solves is avoiding one socket thread trampling over the strings of other client threads. You still have to sync access to the strings when passing them between threads, no matter how many strings you use.

Or, you could simply allocate a new string for each message you send to the UI, and let the main UI thread free the string when done using it. I showed you earlier how to do exactly that.

instead of using a single socket I would use two with two distinct ports

That is not necessary, or desirable. The more ports you open, the harder that makes server administration for network admins to deal with. Use fewer ports, not more ports.

even if not very elegant, in this way I would solve all the problems of race condition, right?

No.

[mark_c]

thanks Remy.
Taking into account my buggy version of the code, the main problem that you Remy identified is the race condition caused by the global variable "msg": but I also ask you if you see deadlok problems, starvation or some unexpected block of the program.

Since the program does not perform any calculation, I do not see exceptions that can make it fail, is it correct?


curiosity:
from the "Embarcadero" documentation I read that all the components and events of the VCL are at the complete disposition of the main thread, it means that all the other threads that are implemented as secondary threads and that want to use methods or events of the main thread must always be synchronized, right?

I wonder: why did Borland not produce a completely thread safe development environment. An acquaintance of mine, told me that Python is completely thread safe, in practice, he doesn't synchronize anything when he develops code, Python does it, but I don't know if it's true.

[rlebeau]

Taking into account my buggy version of the code, the main problem that you Remy identified is the race condition caused by the global variable "msg": but I also ask you if you see deadlok problems, starvation or some unexpected block of the program.

Since the program does not perform any calculation, I do not see exceptions that can make it fail, is it correct?

I already pointed out all of the problems I saw so far. As soon as you need to share data between threads, you have to think about synchronization.

from the "Embarcadero" documentation I read that all the components and events of the VCL are at the complete disposition of the main thread, it means that all the other threads that are implemented as secondary threads and that want to use methods or events of the main thread must always be synchronized, right?

Yes.

why did Borland not produce a completely thread safe development environment.

That is not how UI programing works on Windows. It wasn't their choice. Remember, the original VCL (that still exists today) is largely governed by the design and limitations of the Win32 API. UI elements have thread-specific affinity, they only work properly in the threads that create them. And since the VCL UI is almost always created in the main UI thread, then typically only the main UI thread can access the VCL directly.

An acquaintance of mine, told me that Python is completely thread safe, in practice, he doesn't synchronize anything when he develops code, Python does it, but I don't know if it's true.

I can't answer that, as I'm not a Python developer, I have never touched it. Different programming languages and different frameworks operate in different ways. Read Python's documentation and find out for yourself how it actually works.