Context Navigation

Changes between Initial Version and Version 1 of Ticket #366, comment 4

initial	v1
1	1	Okay, it turns out that fork callbacks (including their priorities) are processed per module. And the module processing order matches the link order: first, LIBC callbacks are processed, then LIBCX callbacks and always the last - EXE callbacks. This way, it's impossible to register a completion callback that would be called after all LIBC callbacks and hence it's impossible to use LIBC Heap from 3rd-party fork callbacks. This looks like a missing feature to me.
2	2
3		A backward-compatible solution would be adding `pfnCompletionCallbackEx` that takes a boolean flag indicating if the callback should be added to the end of the list (executed last) or to the front of the list (executed first). Or, even more compatible, the enmContext argument of the existing `pfnCompletionCallback` may accept a !__LIBC_FORK_CTX_APPEND flag (added to the __LIBC_FORKCTX enum) that will instruct the callback to be added to the end and executed last.
	3	A backward-compatible solution would be adding `pfnCompletionCallbackEx` that takes a boolean flag indicating if the callback should be added to the end of the list (executed last) or to the front of the list (executed first). Or, even more compatible, the enmContext argument of the existing `pfnCompletionCallback` may accept a !__LIBC_FORK_CTX_APPEND flag (added to the !__LIBC_FORKCTX enum) that will instruct the callback to be added to the end and executed last.