Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
M
margo
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
18
Issues
18
List
Boards
Labels
Milestones
Merge Requests
2
Merge Requests
2
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
sds
margo
Commits
771993ce
Commit
771993ce
authored
Sep 07, 2017
by
Shane Snyder
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
update readme with list of v0.2. api changes
parent
d9eee2e2
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
40 additions
and
0 deletions
+40
-0
README.md
README.md
+40
-0
No files found.
README.md
View file @
771993ce
...
...
@@ -182,3 +182,43 @@ Margo allows several different threading/multicore configurations:
* (for servers) a single Margo instance can launch RPC handlers
on different operating system threads
## V0.2 API changes
The following list provides details on new changes to the Margo API starting in
version 0.2:
* margo_init is much more simplified and initializes Mercury and Argobots on behalf of
the user (with margo_finalize finalizing them in that case)
* the prototype is margo_init(addr_string, MARGO_CLIENT_MODE | MARGO_SERVER_MODE,
use_progress_thread, num_rpc_handler_threads)
* margo_init_pool is still available as an advanced initialize routine, where the
user must initialize Mercury/Argobots and pass in an HG_Context and ABT_pools for
RPC handlers and the progress loop
* Margo now has its own RPC registration functions that should be used for registering
RPCs (as Margo is now attaching internal state to RPCs)
* MARGO_REGISTER is basically equivalent to MERCURY_REGISTER, except it takes a
Margo instance ID rather than a Mercury class
* MARGO_REGISTER_MPLEX is mostly the same as above, but allows a user to specify
an ABT_pool to use for a given RPC type
* relatedly, Margo users should now use margo_register_data (rather than HG_Register_data)
for associating user data with an RPC type
* like Mercury, there is a corresponding margo_registered_data call to retrieve the user pointer
* the following Mercury-like functions are now defined within Margo, although it is
still safe to just use the Mercury calls directly (most are just #defined to the
corresponding Mercury call, anyway):
* margo_registered_disable_response
* margo_addr_free
* margo_addr_self
* margo_addr_dup
* margo_addr_to_string
* margo_create
* margo_destroy
* Note that margo_create/margo_destroy are enhancing HG_Create/HG_Destroy with a
cache of reusable handles, so they may be preferable to the Mercury calls
* margo_bulk_create
* margo_bulk_free
* margo_bulk_deserialize
* margo_hg_handle_get_instance and margo_hg_info_get_instance calls have been added for
retrieving a Margo instance ID given a received handle or the HG info struct associated
with the handle
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment