Thread safety with network messages

Unlike previous versions of Minecraft, in 1.8 the networking is performed in its own thread.  This means that your IMessageHandler needs to be very careful not to access and client-side or server-side objects while it is running in its own thread.

For a brief background on multithreaded applications and their perils, see here.  The short summary is-  if your IMessageHandler accesses any client-side or server-side objects, for example World or Minecraft, it will introduce a type of bug called a "race condition" which will lead to random crashes and strange, intermittent bugs and weirdness.

The way to overcome this problem is illustrated in the diagram below.  The essential features are:

1. When your message arrives and your myMessageHandler.onMessage() is called, you should create a "Runnable()" object and add it to the future tasks queue.  The Runnable object will look something like this
   

   player.getServerForPlayer().addScheduledTask(new Runnable()
   {
     public void run() {
       processMessage(message);
     }
   });

2. After adding the Runnable to the queue, your handler onMessage() should return.
3. Later on, the MinecraftServer tick will take your Runnable task off the queue and execute its run() method in the Server thread, which for this example will call myMessageHandler.processMessage(message).
4. Because your message handler is now running in the server thread, it can call any server-side code it wants.

The protocol for messages sent to the client is the same, using the Minecraft "scheduledTasks" queue instead, Minecraft.getMinecraft().addScheduledTask().

For a working example of client and server messages, see here (example 60).

Some notes on the vanilla thread-safety code

The vanilla code uses the same basic strategy as outlined above, with a couple of differences

• After queuing up the Runnable task, it uses a ThreadQuickExitException to abort further processing in the Netty thread.  Java coding experts generally regard this as a misuse of Exceptions, which are supposed to be for exceptional conditions only, not routine flow.  It was probably implemented this way to save some programming effort which was presumably in short supply at the time.  The proper way is to have one method for queuing the Runnable task, and a second method for processing the message on the client/server thread; the vanilla method uses the same method for both threads.
• You will also notice the vanilla code uses thread.isCallingFromMinecraftThread().  This is only necessary because of the ThreadQuickExitException.  You don't need it, because unlike vanilla your handler.onMessage() will always be running in the Netty thread and your handler.processMessage() will always be running in the client / server thread.

Anyway the short summary is - ignore the vanilla PacketThreadUtil.checkThreadAndEnqueue(), it is not good programming style.

Further Links

~Client<-->Server communication
    Vanilla Client<-->Server Communication
    Client<-->Server communication using your own custom messages (SimpleNetworkWrapper)
    Thread safety with Network Messages