mercury
mercury copied to clipboard
Mercury is a C library for implementing RPC, optimized for HPC.
If the client and server disagree on the maximum unexpected message size (for example, if each is choosing them at runtime based on interface settings) then it may cause communication...
While doing some mercury resource cleanup I've been thinking about how to resolve races and gracefully finalize. Consider multiple services built atop mercury, sharing the mercury endpoint. Now, service X...
Compiling on 64-bit OSX systems give a number of conversion warnings, mostly around mixing size_t (of type "unsigned long"), hg_size_t and hg_uint64_t (both of type "uint64_t -> unsigned long long")....
**Reported by robl on 09/22/14** Mercury uses a lot of void pointers. It would be nice if we could annotate the interface to catch problems. see http://hpc-ua.org/hpc-ua-12/files/proceedings/3.pdf and http://clang.llvm.org/docs/AttributeReference.html#type-safety-checking
Several network providers provide direct hardware support for some atomic operations like test_and_set, fetch_and_op, compare_and_swap, etc. It would be nice to have those operations exposed from OFI through the mercury...
We should add benchmark code that NA plugins can use (without the extra HG layer) for both expected/unexpected messages and RMA operations
Currently all the RPC requests posted are initially attached to a single core, this will require some work so that requests can be distributed over multiple cores and progress can...
The decision to do "eager mode" bulk transfers is made inline, without any knowledge of what else might need to be serialized. That is, if you list an hg_bulk_t before...
Currently the NA layer does not allow concurrent progress to be made. We need to add an option so that plugins that support concurrent progress can use that feature.
Currently there seems to be issues with making progress and trigger subcalls within a callback that is called by a first HG_Trigger() call.