In the past ipc system, we passed a buffer into coroipcc_dispatch_recv and the buffer was memcpied to from the shared memory segment. This resulted in an extra memcpy and the need to have a buffer of appropriate size to return the data into. Jim recently added a patch which verified the size of the buffer which broke every service since they all used undersized buffers.
This patch uses the mmap system call to create a shared memory area backed by a file for the dispatch data. The file is removed and is not saved. The mmap magic creates a segment twice the size of the dispatch data, then maps the first dispatch segment into it, then maps the same dispatch segment into the second part of it. This allows us to do a direct memcpy and rely on the OS VM subsystem to map the reads or writes to the appropriate locations. The end result is that we no longer have to allocate a buffer in our dispatch routine and we can directly use the dispatch buffer's data in our applications. memcpy gone, memory utilization reduced with a possible effect on portability. Now all the corosync and openais services work properly. For systems that don't support the mmap feature we depend on, we can work around this by allocating a large enough buffer in dispatch_get and free it in dispatch_put and do a memcpy. Then conditionally compile the mmap routines that create the mapped circular buffer. Interested in experiences on Darwin/BSD systems. Regards -steve _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
