Because Interix supports the majority of UNIX memory management calls, porting code by using memory management is generally straightforward. However, because there are a few specific differences, this section discusses how to addressthe differences in your code.
Interix supports most memory functions. The platform-specific memory management functions shown in Table 10.9 are not supported and code will need to use the alternative functions.
Function Name | Description | Suggested Interix Replacement |
---|---|---|
alloca | Memory allocator | Use malloc(size_t size ) and call free() because space is not automatically freed on return. Potential performance issues are possible because alloca allocated memory on the stack frame of the caller instead of the heap. |
cfree | Debugging memory allocator. | free(void *ptr) |
getpagesize | Gets system page size. | Always returns 65536 (64K), regardless of the actual Windows page size. The getconf(_SC_PAGE_SIZE) and sysconf(_SC_PAGE_SIZE) functions also always return 65536 (64K). |
mallocctl | MT hot memory allocator. | Not supported. There may be open source versions of other allocators which can be used. |
mallopt | Provides for controls over the allocation algorithm. | None; the supported malloc() has no controllable options //mallopt |
memalign | Debugging memory allocator. | No support or equivalent in Interix. |
valloc | Equivalent to | malloc(size_t size) |
watchmalloc | Debugging memory allocator. | No support or equivalent in Interix. |
Interix supports memory-mapped files by using the mmap function. The lengthof the mapped space, in bytes, is rounded up to the nearest multiple of sysconf(_SC_PAGE_SIZE) . This means that the value returned by sysconf(_SC_PAGE_SIZE) (or sysconf(_SC_PAGESIZE) ) is not the virtual-memory page size used by the system, but the value used by the mmap call. Code should work without modification unless it assumes page sizes to be smaller than 64 KB; most applications are written without any assumption regarding page size.
For an example of UNIX code that ports to Interix without change, see Memory-Mapped Files in Chapter 9, Win32 Code Conversion.
Shared memory permits two or more processes to share a region of memory. Datais not copied as part of the communication process. Instead, the same physical area of memory is accessed by both the client and the server. For this reason, shared memory performance is considered the best of all interprocess communication (IPC) methods .
Interix supports all of the System V IPC mechanisms, including the shared memory routines shmat , shmctl , shmdt , and shmget .
The command-line interfaces ipcs and ipcm are also provided for the management of shared memory segments. The ipcs interface reports the status of interprocess communication objects. The ipcm interface removes an interprocess communication identifier, such as a shared memory segment.
For an example of UNIX code that ports to Interix without change, see Shared Memory in Chapter 9, Win32 Code Conversion.
Code that uses shared memory must ensure that the processes accessing shared memory are not attempting to access the shared memory resource simultaneously . This is particularly troublesome if one or both are writing to the same shared memory area. To address this, UNIX provides the semaphore object.
But there are two sets of functions for semaphores. The POSIX real-time extensions are used for thread synchronization. The System V semaphores are commonly used for process synchronization.
The POSIX real-time extensions and threads are not supported by Interix.
Interix supports all of the System V semaphores, including the shared memory routines semctl , semget , and semop .
The command-line interfaces ipcs and ipcm are also provided for the management of semaphore objects. The ipcs interface reports the status of interprocess communication objects. The ipcm interface removes an interprocess communication identifier, such as a shared memory segment.