Thread architecture, thread security, and memory management

Thread architecture, thread security, and memory management in XMPPFramework

The XMPPFramework of Version 3 brings a lot of parallelism and great performance improvement. How to use it?
Grand Central Dispatch
Writing multi-threaded code has always been a difficult and prone to problems. GCD makes it easy to write multi-threaded code to a large extent.
GCD technology is a new Apple technology. This technology eliminates the need to consider how to create a thread and how many threads to create.
Performance impact.
On the one hand, it is very expensive to create a thread. Slow and costly. Too many thread switching also wastes CPU time.
On the other hand, the system will not give a simple answer to tell you how many threads to create is the most appropriate.
These are all related to the system load and are constantly changing. The system knows the exact load. Therefore, a system should be handed in.

GCD solves these problems with a simple Abstraction:
Now you only need to use dispatch queues. They are ultra-lightweight and you can create a large number of queue.
The GCD library will automatically manage appropriate thread pools and execute the queues you assign on the threads in the thread pool.

Therefore, dispatch_queue is not a thread, but an abstract design that allows you to stop thinking about thread terms.
See the following example:

// Creating a dispatch queue is a lightweight operation.// Creating a thread = 512 KB// Creating a queue = 256 Bytes !// // We're going to create a serial queue.dispatch_queue_t myQ = dispatch_queue_create("my q name", NULL);// Placing a work item in a GCD queue is a lightweight operation.// In fact, it requires only 15 instructions.// By comparison, setting up a thread, and assigning work to it// can require hundreds of instructions// and take more than 50 times longer.dispatch_async(myQ, task1);dispatch_async(myQ, task2);dispatch_async(myQ, task3);

Are all task1-task3 running on one thread? NO. Do not treat the queue as a thread ......
This may be the case:
Task1-> Thread D
Task2-> Thread E
Task3-> Thread F
It may also be like this:
Task1-> Thread Z
Task2-> Thread D
Task3-> Thread Z
This is not important. We have created a serial queue, so the task will be executed in order. Task 2 does not start until Task 1 ends.

Parallel Execution through queues
XMPPFramework achieves parallelism by allowing all modules and proxies to run in their own queues. Let's dive deeper into the code
Let's see:
Whenever you add a proxy, you also need to specify dispatch_queue, which is your proxy method
Called.

The code above specifies that the proxy method is called on the main thread. You can create and specify your own queue to easily parallelize your XMPP code.

This is what xmppStream does when it wants to call your proxy method.

It is easy to avoid deadlocks-the proxy is always called asynchronously.

Thread Security
If you call
[XmppStream addDelegate: self delegateQueue:...];
Do not forget to make the following calls in the appropriate places (maybe in dealloc, or even before ):
[XmppStream removeDelegate: self];
This should be applied to any module that you may have added a proxy.

Memory Management
XML is a tree structure. The nodes you are dealing with have fathers and children. The xml api is designed to allow you to go from top
The entire tree. Therefore, if you hold a subnode, the entire tree may not be released. So it should be
Create a copy of a member node instead of holding the child node.