Skynet stepped on the pit record (3) The possible consequences of the suspension of skynet.call in practice.

       When I first started using skynet, I already knew that the call method would hang. But to this day, I can't fully understand the meaning of this suspension. Until I ran into this problem. Make this record after resolution.

       1. First describe what happened.

        

       Regardless of why so many operations on db (too many reasons). Under this requirement, I originally wanted the execution order to be 1234, but in fact it was 1324. This will cause 3 to get the data before the 2 update. The number of participations today will be at the time 4 is executed, and there is no update content that can be updated to 2.

       2. Why does this happen?

       First of all, we must understand the lua coroutine. Only one cooperative program is running at any given time, and this running cooperative program will only be suspended when it is explicitly required to be suspended. Generally, when using coroutines, because of the performance of the cpu, it makes us feel similar to multithreading. But the point is that at the same time, only one coroutine is running, and when he surrenders the cpu, the cpu will go back to deal with other coroutines.

       In the above case, it is because skynet.call is called in step 1. This thing will hang the coroutine, which is to give up the cpu. Then the cpu processed the following coroutine, so it called 3 first.

       3. What to do

       There are two methods: a. Modify the business and write these two additions together.

                            b. Use message queue, skynet.queue. (The code is very simple, just a few lines, that is, the method of the current coroutine is processed, and then the method of the next coroutine is called) (Senior Yunfeng also wrote in the blog, skynet.queue, is used to deal with this multi-coroutine, It is also necessary to ensure the order.)

       4. Precautions for handling, when using skynet.queue, you must ensure that the order of throwing into the queue is 1234. Because I myself did not understand the call hang well, I let the above two coroutines lose the methods separately In the queue (stepping on the pit again to deepen understanding), the order of the last thrown in is 1324. . . . After searching for a long time, I found it. Again, skynet.call will hang the coroutine. In fact, in many game businesses, there will be this kind of scene, which requires more attention. (If it is about the modification of important data, the trouble will be big, such as gold coin changes, etc.)

       5. Although it was solved technically, in the end I modified the logic and wrote the two methods into one. There is no need to perform four DB operations. But this time it did deepen my understanding of coroutine hangs.

Guess you like

Origin blog.csdn.net/banfushen007/article/details/108667113