TASK_VM_INFO_COUNT is the size of memory taken by task_vm_info_data_t structure. This method casts task_vm_info_data_t to task_info_t so it has to know how much memory the original structure takes.

Docs for task_info function: https://www.gnu.org/software/hurd/gnumach-doc/Task-Information.html
Definition for TASK_VM_INFO_COUNT (code): https://github.com/xybp888/iOS-SDKs/blob/master/iPhoneOS13.0.sdk/usr/include/mach/task_info.h#L406

1. The purpose of this method is explained in the summary.

When memory events occurs event handler uses this method to set memory error message. Then NSE instance checks before calling content handler if the memory error message was set. If it was it atomically gets it and sets to null. Then it uses the memory error message to modify notification content (for staff users only).

2. NSLock has tryLock method which is non-blocking. But perhaps it is a premature optimization? I didn't want to block every thread of NSE process when calling this method. This is different from the case in child differential where we synchronize access to instance variable since it is a class variable set per entire process.
3. It might not be called if an exception is thrown in the middle of its execution provided that this error does not kill the process. Unless we use @synchronized we don't have a way to guarantee that unlock will be called however it is unlikely that it won't be. I decided that it is better not to block every thread when calling this method than guarantee 100% sure that unlock will be called.

Assuming that some error occurs that prevents unlock from being called but doesn't kill the process then we just stop displaying memory event notifications but other NSE functionalities remain unchanged.

There are three events possible:

• NORMAL
• WARNING
• CRITICAL

We could listen to WARNING but I am afraid we would be getting to much events and didn't have a clear picture of what is going on.

Unfortunately there is no way to tell when NSE process is going to terminate - there is not callback we can overwrite.
There is a method dispatch_suspend: https://developer.apple.com/documentation/dispatch/1452801-dispatch_suspend, but the docs advice that the memory source must be in resumed state before it is dealocated. That said if we were to suspend it we would have to ensure it is resumed befre NSE terminates which we can't.

Alternatively we could create and delete memory source at the beginning and at the end of didReceive... callback. However there are disadvantages. The first is that we would have to synchronise it so that only one NSE instance creates and deletes memory source at a time (it is a per process variable). The other is that we would miss events that occur in between didReceive... callbacks.

Signal keeps a global instance of memoruSource and they don't call any suspension or deactivation/cancellation methods: https://github.com/signalapp/Signal-iOS/blob/6cc18788850558251db5f772ca62bce6b576dfc4/SignalNSE/NSEContext.swift

I don't think that any value is copied here twice. The first time we copy the current value of memoryEventMessage (or not if it is nil). Then we overwrite memoryEventMessage with the copy of it new value (provided as a method argument). Then we return the old value. This is basically getAndSetAtomically that atomically reads old value, writes the new one and returns the old one. No value is copied twice.