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

Who manages the lifetime of components? #127

Open
boblehest opened this issue Jul 20, 2018 · 4 comments

Comments

Projects
None yet
3 participants
@boblehest
Copy link

commented Jul 20, 2018

Reading the http example, I was curious about who manages the lifetime of the http component (created here), and it seems that the component itself is moved into the stream's callback, and kept there.

Who's supposed to drop the component when it's outlived its purpose? Even closing the returned stream does not cause the component to get dropped. I managed to drop it by replacing the stream's callback (http.set_callback(|_| ());). This seems very unergonomic. Am I doing it wrong? Any input is appreciated.

@antoyo

This comment has been minimized.

Copy link
Owner

commented Jul 20, 2018

Do you save the result of execute somewhere (perhaps by moving it into a callback)?
The callback should be dropped by itself when the EventStream returned by execute is dropped.
If you save it in your model, you could save it as an Option so that you can take() it to destroy the component.

Edit: Wait, I think there's something wrong in the example.
Since the http stream is dropped, the callback should never be called.
I'll have to check in more detail.

@boblehest

This comment has been minimized.

Copy link
Author

commented Jul 21, 2018

Just so we're on the same page; I'm only talking about what I'm seeing in the example — not about any code I've written myself. And when I say that the component is moved into the stream's callback, I'm referring to what happens here (in init_component, which is called by execute).

The callback should be dropped by itself when the EventStream returned by execute is dropped.

Yeah, that's what I was expecting, but I noticed that it's not what's happening. :/

@antoyo

This comment has been minimized.

Copy link
Owner

commented Jul 21, 2018

It seems there's a reference cycle.
I'll check that.

@kevinpoitra

This comment has been minimized.

Copy link

commented Jan 24, 2019

It seems like I'm running into the same bug. In an application I'm writing, I facilitate HTTP requests exactly as the http example does. What I'm noticing is that if I wrap the code that creates the http EventStream and the execute function itself in a for loop (to help exacerbate the issue) and run that for loop every few seconds is that:

  • The memory usage of the program will rise from a starting point of ~14MB to ~400MB, increasing steadily with each iteration of the loop. It'll seemingly stop being able to issue new HTTP requests at random points every time I restart the application - sometimes at 70MB, sometimes at 400MB, and anything in between.
  • After a while, the program will slow down to a crawl.
  • Eventually, (I assume) the program will consume all available handles. This not only causes the program to be unable to issue any further HTTP requests, but it also locks up the entire computer - Firefox, for example, won't load any pages or even show any connection errors, it'll just show a white screen and do nothing, and similar issues can be found with any application that connects to the internet. As soon as I close the application, Firefox and everything else starts working again.

@antoyo antoyo referenced a pull request that will close this issue May 14, 2019

Open

Remove GSource #171

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.