Skip to content

Fix example code in README.md#12

Open
oddman621 wants to merge 1 commit into
stetre:masterfrom
oddman621:patch-1
Open

Fix example code in README.md#12
oddman621 wants to merge 1 commit into
stetre:masterfrom
oddman621:patch-1

Conversation

@oddman621

@oddman621 oddman621 commented Sep 24, 2024

Copy link
Copy Markdown

Add glfw.destroy_window(window) to last line.

Without that, the program halts when exiting.

Fixed example codes: Add glfw.destroy_window(window) to last line.
@stetre

stetre commented Sep 27, 2024

Copy link
Copy Markdown
Owner

Hi, please try the latest commit to see if it fixes the problem you are encountering.
Thank you.
Ste

@oddman621

Copy link
Copy Markdown
Author

Still experiencing freezes on shutdown. Does this issue only occur in my environment?

@stetre

stetre commented Sep 28, 2024

Copy link
Copy Markdown
Owner

What platform are you running it on?

@oddman621

Copy link
Copy Markdown
Author

Windows 11 x64
MSYS2 MinGW64

@stetre

stetre commented Sep 30, 2024

Copy link
Copy Markdown
Owner

I see. I'm using GNU/Linux (Ubuntu) and I've never experienced this problem. So, yes, it looks like a system-related issue.
Have you tried other examples to see if they also hang on exit when the window is not destroyed explicitly?

@oddman621

Copy link
Copy Markdown
Author

Yes, all of them have freezing issues except version.lua and simple.lua.

  • version.lua: doesn't create windows,
  • simple.lua: explicitly destroys windows for some reason?

@oddman621

Copy link
Copy Markdown
Author

And of course, when I remove glfw.destroy_window(window), simple.lua also freezes when quitting.

@stetre

stetre commented Oct 1, 2024

Copy link
Copy Markdown
Owner

simple.lua is an almost verbatim translation from C to Lua of an original GLFW example. I just left the destroy_windows() call as in the original, but it is not essential. Or at least, it should not be...

The idea is that the explicit destruction of objects can be omitted when the program is exiting. This is especially useful when the exit is caused by a scripting error. You can easily test this scenario by adding a call to a non-existing function (e.g. foo()) before the glfw.destroy_window() call. On your system, this would most likely cause the program to freeze and the explicit call to destroy_window() would be no cure in this case.

I have to do some thinking on how to tackle this problem, which looks a bit strange to me and may have to do with how windows and msys2 handle the atexit() code. I'll turn this pull request in an open issue.

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

Successfully merging this pull request may close these issues.

2 participants