GitLab

switch to margo_thread_yield in sparkline fn

Closes #53

See merge request !23

Turns out you cannot set these vars to "yes".  Must be an integer: 0 for
off or 1 for on

Srinivasan Ramesh authored Feb 18, 2020 and Philip Carns committed Feb 19, 2020

- guarding profiling logic using the profile_enabled flag
- generate the self_addr hash only once during init and use
  this hash in subsequent breadcrumb logic

Added pre-finalize callbacks

See merge request !19

Add breadcrumb profiling logic

See merge request !18

Srinivasan Ramesh authored Oct 18, 2019 and Philip Carns committed Oct 18, 2019

Put profiling + writing logic behind MARGO_PROFILE, writing all profiles to current working directory

- just disable tests if we can't find it, we can still build library

Margo RPC instrumentation mechanism

See merge request !16

added provider finalize callbacks

See merge request !17

- The logic for relaying RPC breadcrumbs from RPC requests to threads is
  now internal to margo (which is good), just moving comment
  accordingly.

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.