GitLab

decoupled DEFINE_MARGO_RPC_HANDLER into multiple macros internally so the internal macros can be used in exotic cases, like in Thallium

- first draft, not complete

Implemented opaque margo_request

See merge request !15

- workaround for potential of Mercury forward calls getting stuck while
  Margo is in a blocking progress call

- make sure that we allow for the possibility of ULTs in the same pool
  as the progress loop being resumed by external events
- rely on abt statistics rather than results of Mercury progress and
  trigger calls to determine when to yield.  Mercury return codes can be
  slightly ambiguous when not blocking.
- this prevents periodic stalls when Margo is used in conjunction with
  abt-io and/or self forward calls in Mercury.

This reverts commit 8c38f5d6.

- This change makes margo more aggressive in terms of when to busy spin.
  It will now do so any time other ULTs are present in the same progress
  pool (whether runable or not) in case ULTs are resumed by an external
  resource and need to be executed promptly.
- Will still sleep gracefully for idle daemons and within blocking
  client calls when no explicit additional ULTs are in use.

- reported by Michael Brim

- also add warning messages if things don't match up on shutdown
- fixes #48

- also refactor argobots tunables into a small subroutine

add bulk pool implementation

See merge request !10

add margo_init_opt() variant to pass Mercury opts

Closes #44

See merge request !9

- proposed by Tommaso Tocci 
- follows the naming convention of the Mercury API
- retains existing margo_init() for compatibility

- fixes #43
- note that we use Argobots origin/master now
- remove recommendation to disable Hg checksumming (the default checksum
  routine is much faster now)

Fix 'multiple definition' errors on some compilers.

See merge request !7

- if dedicated rpc threads are used, they should use _WAIT scheduler as
  well

added margo_deregister

See merge request !6