if a specific hmbdc network transport (for example tcpcast) supports message with memory attachment, the message needs to be derived from this base - as the FIRST base, so it can be handled properly by the hmbdc network transport when sending and receiving it
More...
#include <Message.hpp>
|
AfterConsumedCleanupFunc | afterConsumedCleanupFunc |
|
void * | attachment |
|
size_t | len |
|
if a specific hmbdc network transport (for example tcpcast) supports message with memory attachment, the message needs to be derived from this base - as the FIRST base, so it can be handled properly by the hmbdc network transport when sending and receiving it
user on the sending side cannot directly free the attachment, instead the user can provide a callback func and hmbdc will call it - by default, the callback behavior is to call free on attachment
- Examples:
- rmcast-cp.cpp.
hmbdc::app::hasMemoryAttachment::hasMemoryAttachment |
( |
| ) |
|
|
inline |
default ctor
allocate and release thru heap
hmbdc::app::hasMemoryAttachment::hasMemoryAttachment |
( |
char const * |
fileName | ) |
|
|
inline |
file mapped memory
- Parameters
-
size_t hmbdc::app::hasMemoryAttachment::map |
( |
char const * |
fileName | ) |
|
map this object's attached memory to a file
the afterConsumedCleanupFunc is automatically set to do the unmap
- Parameters
-
fileName | file to map into memory |
- Returns
- size of the file mapped
void hmbdc::app::hasMemoryAttachment::unmap |
( |
| ) |
|
|
inline |
does the reverse of map
pointing to a func that handles cleaning up the attachment it is automatically set, but user can change it as desire when the sending side is done with this message, this is called by hmbdc automatically. however, this is not called on the recv side since only the user code knows when to call it
The documentation for this class was generated from the following file: