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

Dynamically Deleting Window Consoles #60

Open
JohnDog3112 opened this issue Dec 6, 2024 · 1 comment
Open

Dynamically Deleting Window Consoles #60

JohnDog3112 opened this issue Dec 6, 2024 · 1 comment
Assignees
Labels
bug Something isn't working

Comments

@JohnDog3112
Copy link
Collaborator

As mentioned in #59 I came upon a potential issue for how I currently handle Windows. To summarize, the window has a user drawable sub-canvas that it uses to separate what a WASM application can draw on from what the window library can draw on. This sub-canvas is twrConsoleCanvas containing an off-screen canvas so the WASM application can draw on it and allows the window to draw the sub-canvas on its main canvas.

The problem comes with the potential of closing a window where the problem becomes two-fold.

  1. When "closing" a window, the window console should be deleted to free the memory it's using. However, there is currently no way to delete a console since they are all registered globally.
  2. Additionally, a window should delete it's sub-canvas which has the same issue as 1. do to being a console.

So, my question is the following: would there be any issues with adding a function to "unregister" a library so it can be freed?

The main potential issues I can think of are as follows:

  1. I would think it has all the same issues as using free() on memory in C except with the added challenge of being arbitrarily referenced by other programs.
  2. There isn't really any way to track what applications are referencing a console other than the programmer handling it all themselves

For issues specific to windows, I think some potential ways to mitigate the above issues are as follows:

  1. Send events for window close events
  • one problem is that with an async WASM program it might be possible for the program to be waiting on something when it gets the event and continue executing assuming the window still exists. It could also potentially happen with a sync program if the following somehow happens: window event is sent -> window is closed -> window event is handled assuming window is open -> window close event is received.
  • This could potentially be fixed by keeping the library/console alive until the close event is received and finished/acknowledged.
  1. Directly bind a WASM program to a window so closing a window also closes the WASM application as well.
  • makes multiple windows harder requiring a WASM program per window with some communication protocol
  • Removes issue of window close acknowledgment
  1. Make window and canvas operation return a boolean or something similar for the "success" of an operation so closed windows can return errors that C is able to handle and catch.
@JohnDog3112 JohnDog3112 added the bug Something isn't working label Dec 6, 2024
@JohnDog3112
Copy link
Collaborator Author

Looking into it a bit further, it seems Windows method for this is with events like talked about above in conjunction with waiting for an acknowledgment. In this way, the application has the chance to cleanly handle the window closing and it's given an opportunity to cancel it. That way, if the program closes itself when the window does, they can stop itself from cloning while doing important tasks such as saving a file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants