Change Details

**Brief Summary** OS wrapper layers help to create Mutex, Semaphores, and Thread on an OS. The wrapper was designed to be implemented on platforms that dynamically allocate memory or objects from a predefined OS memory pool. The current shape of the OS wrapper is not a good fit for work with operating systems that require manual memory management. For example, if the child thread created in ns_test_helpers.c does a simple os_wrapper_thread_exit(), this does not give any opportunity for manually-managed thread resources to be freed; this leads to a memory leak. Therefore **os_wrapper_current_thread_suspend() **and **os_wrapper_thread_delete()** are introduced to aid scenarios where manual memory management is required. The removal of ** os_wrapper_thread_exit()** is warranted as it encourages applications to avoid memory leak scenarios by requiring applications to remember to call **os_wrapper_thread_terminate()**. If we were to keep **os_wrapper_thread_exit()** around, this would impose undue cognitive overhead on wrapper users by making **os_wrapper_thread_exit()** do something other than exit the current thread (on platforms requiring manual memory management); an **os_wrapper_thread_exit()** implementation could not actually exit a thread on a manual memory managed OS, as the thread must remain valid until clean up time, and exiting the thread would invalidate the OS's thread resource. Also to avoid memory leaks on operating systems that use manually managed dynamic memory allocation but not from static memory/objects pools, allowing them to free after usage. Remove "get_handle" because it's not possible to implement it efficiently on systems that require manual memory management. The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources to be freed which are not managed by the OS. For example: ``` struct { os_handle; external_to_os_resource; } ; ``` The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle because implementations can't always create an os-wrapper handle from an OS handle. In this case, the os-wrapper handle could be a pointer to this struct, but could not be just the os_handle directly. Further **os_wrapper_current_thread_get_priority()** is used to avoid confusion between the top and bottom layer handles because the older implementation can refer to different object types when operating across multiple layers.

**Brief Summary** OS wrapper layers help to create Mutex, Semaphores, and Thread on an OS. The wrapper was designed to be implemented on platforms that dynamically allocate memory or objects from a predefined OS memory pool. The current shape of the OS wrapper is not a good fit for work with operating systems that require manual memory management. For example, if the child thread created in ns_test_helpers.c does a simple os_wrapper_thread_exit(), this does not give any opportunity for manually-managed thread resources to be freed; this leads to a memory leak. Therefore **os_wrapper_current_thread_suspend() **and **os_wrapper_thread_delete()** are introduced to aid scenarios where manual memory management is required. The removal of ** os_wrapper_thread_exit()** is warranted as it encourages applications to avoid memory leak scenarios by requiring applications to remember to call **os_wrapper_thread_terminate()**. If we were to keep **os_wrapper_thread_exit()** around, this would impose undue cognitive overhead on wrapper users by making **os_wrapper_thread_exit()** do something other than exit the current thread (on platforms requiring manual memory management); an **os_wrapper_thread_exit()** implementation could not actually exit a thread on a manual memory managed OS, as the thread must remain valid until clean up time, and exiting the thread would invalidate the OS's thread resource. Also to avoid memory leaks on operating systems that use manually managed dynamic memory allocation but not from static memory/objects pools, allowing them to free after usage. Remove "get_handle" because it's not possible to implement it efficiently on systems that require manual memory management. The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources to be freed which are not managed by the OS. For example: ``` struct { os_handle; external_to_os_resource; }; ``` The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle because implementations can't always create an os-wrapper handle from an OS handle. In this case, the os-wrapper handle could be a pointer to this struct, but could not be just the os_handle directly. Further **os_wrapper_current_thread_get_priority()** is used to avoid confusion between the top and bottom layer handles because the older implementation can refer to different object types when operating across multiple layers.

**Brief Summary** OS wrapper layers help to create Mutex, Semaphores, and Thread on an OS. The wrapper was designed to be implemented on platforms that dynamically allocate memory or objects from a predefined OS memory pool. The current shape of the OS wrapper is not a good fit for work with operating systems that require manual memory management. For example, if the child thread created in ns_test_helpers.c does a simple os_wrapper_thread_exit(), this does not give any opportunity for manually-managed thread resources to be freed; this leads to a memory leak. Therefore **os_wrapper_current_thread_suspend() **and **os_wrapper_thread_delete()** are introduced to aid scenarios where manual memory management is required. The removal of ** os_wrapper_thread_exit()** is warranted as it encourages applications to avoid memory leak scenarios by requiring applications to remember to call **os_wrapper_thread_terminate()**. If we were to keep **os_wrapper_thread_exit()** around, this would impose undue cognitive overhead on wrapper users by making **os_wrapper_thread_exit()** do something other than exit the current thread (on platforms requiring manual memory management); an **os_wrapper_thread_exit()** implementation could not actually exit a thread on a manual memory managed OS, as the thread must remain valid until clean up time, and exiting the thread would invalidate the OS's thread resource. Also to avoid memory leaks on operating systems that use manually managed dynamic memory allocation but not from static memory/objects pools, allowing them to free after usage. Remove "get_handle" because it's not possible to implement it efficiently on systems that require manual memory management. The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources to be freed which are not managed by the OS. For example: ``` struct { os_handle; external_to_os_resource; } { os_handle; external_to_os_resource; }; ``` The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle because implementations can't always create an os-wrapper handle from an OS handle. In this case, the os-wrapper handle could be a pointer to this struct, but could not be just the os_handle directly. Further **os_wrapper_current_thread_get_priority()** is used to avoid confusion between the top and bottom layer handles because the older implementation can refer to different object types when operating across multiple layers.