Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • M margo
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 13
    • Issues 13
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 1
    • Merge requests 1
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • sds
  • margo
  • Issues
  • #31

Closed
Open
Created Oct 09, 2017 by Matthieu Dorier@mdorierOwner

starting/stopping progress loop

We might want to add functions to start and stop the progress loop.

When calling margo_init on a server and specifying that the progress loop runs on an additional execution stream, we actually make the progress loop start before RPCs have been registered. Consequently, a client may try to contact the server and get as a response that the RPC id doesn't map to any RPC handler. I have had that happening in my kNN code and I suspect this was the reason.

The second problem with the fact that margo_init starts the progress loop is that we don't protect the margo parameters: if you call margo_set_param and set a parameter right at the moment this parameter is being used by the progress loop, you can end up with strange behaviors.

I would advocate for a model where we do margo_init followed by an explicit margo_start (maybe with some margo_set_param in between), and also provide a margo_stop to allow another thread to explicitly pause the progress loop.

What do you think?

Assignee
Assign to
Time tracking