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

Overthink Channel receive of Environment #93

Open
fel115 opened this issue Oct 3, 2023 · 8 comments
Open

Overthink Channel receive of Environment #93

fel115 opened this issue Oct 3, 2023 · 8 comments
Labels
enhancement New feature or request

Comments

@fel115
Copy link
Collaborator

fel115 commented Oct 3, 2023

The problem is, that if the Environment loop is only called every minute, so it can only receive MPSC-Channel messages every minute. So if we need to RestoreBaseline we need to wait a max of one minute to RestoreBaseline. The idea is to use two loops, one for handling the Envirionment data and one for receiving the MPSC-Messages. But RememberBasline and RestoreBaseline need to know the new data gathered by the other loop. Maybe a communication between the loops? Or Maybe using tokio::macros::select to execute the path which is triggered.

@fel115 fel115 added the enhancement New feature or request label Oct 3, 2023
@markus2330
Copy link
Contributor

Thank you for creating this issue!

"So if we need to RestoreBaseline"

Do you mean in the case of signals?

@fel115
Copy link
Collaborator Author

fel115 commented Oct 8, 2023

Thank you for creating this issue!

"So if we need to RestoreBaseline"

Do you mean in the case of signals?

Yes, especially in case of signals. Here the program should terminate fast and save all data.

@markus2330
Copy link
Contributor

Why not make an explicit additional saving when the program terminates independent of these loops?

@fel115
Copy link
Collaborator Author

fel115 commented Oct 8, 2023

Yes, this was another idea, to use a Mutex of Environment and do the restore in the signals module.

@markus2330
Copy link
Contributor

Buttons already implements Drop, which also should be executed on shutdown. The same technique could be used for the sensors module.

I don't think that the signals module should know anything from the other modules.

@fel115
Copy link
Collaborator Author

fel115 commented Oct 9, 2023

Buttons already implements Drop, which also should be executed on shutdown. The same technique could be used for the sensors module.

Do you mean the Environment module? So we store the baseline in the Drop function.

I don't think that the signals module should know anything from the other modules.

So the signals shouldn't have a channel to the modules? Or do you mean the mutex shouldn't be passed to the signals module?

@markus2330
Copy link
Contributor

Do you mean the Environment module? So we store the baseline in the Drop function.

Yes, exactly 🚀

So the signals shouldn't have a channel to the modules? Or do you mean the mutex shouldn't be passed to the signals module?

I meant that the signals should not have a reference to the Environment (or any other module), thus they should be unable to store the baseline.

Can you please update the architecture picture? Dependencies like this should be visible, as they are important.

@markus2330
Copy link
Contributor

Doesn't seem to be fixed?

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

No branches or pull requests

2 participants