Trying to understand the reason for using both threading and non-blocking TryReceiveFrameString

[Abdul-Mukit]

Hi,
Thank you, again for the repo. I am trying to learn from your codes. I see that you created a new thread and commented here that we need a new thread so that unity can do other stuff. I assume the new thread will be running the client in "parallel".
Then in here you said that if we used ReceiveFrameString() we would block unity from doing other stuff.

My first question is that, if we have already started a new thread to deal with blocking receive function, then why do we need to use TryReceiveFrameString(). Even if this new thread gets blocked for using ReceiveFrameString(), why would it hamper unity?

If we used ReceiveFrameString() and the new thread gets blocked until it received a response from the server isn't that good for the processing power? I see in your ToDo (in the readme.md) that, the current implementation is calling TryReceiveFrameString() in a loop without any delay which is bad for processing power.

Again, thank you for your time.

[offchan42]

Thanks for the question.
Unity will wait for every thread to finish, otherwise, it becomes frozen. The main thread will already be finished but the NetMQ thread will get stuck listening for messages indefinitely if you use ReceiveFrameString().

But if you use TryReceiveFrameString(), you can force the thread to finish by setting Running variable to false.
When you stop playing, the HelloClient will call Stop() function of the thread, which simply sets Running as false.

If you want to reduce compute, it's better to use TryReceiveFrameString() with timeout.

[Abdul-Mukit]

Thank you. Got it now.

About,

If you want to reduce compute, it's better to use TryReceiveFrameString() with timeout.

Do you mean something like Thread.sleep() inside run(), to maintain a 60-fps (or unity frame-rate)?

[offchan42]

I mean that the function itself has timeout parameter that you can provide. If you use Thread.sleep you will block the thread from reading the message from server.
You need to check whether they have the timeout parameter in the TryReceiveFrameString() function.