Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request for a few documentation notes #6

Open
joel99 opened this issue Dec 2, 2022 · 1 comment
Open

Request for a few documentation notes #6

joel99 opened this issue Dec 2, 2022 · 1 comment

Comments

@joel99
Copy link
Contributor

joel99 commented Dec 2, 2022

  1. What tells modules to quit? For example, there is no break statement in Request.py example even though there is a subscription to MT_EXIT. Moreover, what happens if there's no subscription to the exit signal - is the module just rogue?
    print("Received message", msg.GetHeader().msg_type)
  2. How does the looping logic in individual modules work? For example, in Request; every loop there's a message read in. What if no one sent a message - does MM send a heartbeat? What if multiple modules sent messages faster than the loop clock? Does MM send a batch? (I expect the most intuitive things for example would be sugar like async/await but since there's a loop with each module keeping its own clock things are now confusing.
  3. Does the system get overloaded if everyone loops with no sleep? Are practical modules supposed to sleep, what, 10ms?
@jmw182
Copy link
Member

jmw182 commented Feb 28, 2023

Sorry @joel99 , I wasn't tagged in this and I don't check this repo often, so I did not see this until now.

Requests.py is not a very good example, so that's probably causing some of your confusion. Also, I am deprecating the python bindings in this repo. The new python client is here: https://github.com/pitt-rnel/pyrtma/

  1. There isn't really anything built-in that tells modules to quit. The MT_EXIT signal is defined, but it's not handled internally, the user still needs to subscribe to it and handle cleanup when the signal is received. The Request.py example is incomplete, for some reason it subscribes to the signal but it doesn't do anything with it. If MessageManager closes, than every module will crash on the next rtma call (whether that's ReadMessage, SendMessage, etc.).

  2. It's not typical to have a sleep like in Request.py. Most of the time the loop timing is handled by ReadMessage, which can be called in three ways: blocking (will block indefinitely until a message is received, or error if the connection is closed), timeout (will block until a message is received OR the timeout is elapsed), non-blocking (will return immediately, whether a message is available or not). You will typically see something like M = ReadMessage(0.1) (wait for up to 100 ms for a message) or M = ReadMessage(0) (check for a message without blocking). When ReadMessage has a timeout greater than the expected message rate (or is blocking), then the message rate effectively sets the loop rate, since most of the time is spent waiting for a message.

  3. No, there's no need to sleep. It usually makes sense to use a timeout, unless there are things that have to happen in the loop at a faster rate than messages come in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants