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

Exception (and thread) safety/awareness of hello_imgui question #17

Closed
MichaelKv opened this issue Apr 28, 2021 · 5 comments
Closed

Exception (and thread) safety/awareness of hello_imgui question #17

MichaelKv opened this issue Apr 28, 2021 · 5 comments
Labels
documentation Improvements or additions to documentation

Comments

@MichaelKv
Copy link

Hello. Imgui itself is not exception safe or exceptions aware but I know how to deal with this mainly C code. What is about hello_imgui? I consider it as a kind of window management system for Imgui that hides some its mechanics so I must be sure I may or may not use exceptions with hello_imgui.
Sorry for the noob question but it is a blocker for me so I want to be sure about the facts, approaches and plans. Thank you.

P.S. It would be worth to mention about thread safety/awareness too.

@pthom
Copy link
Owner

pthom commented Apr 29, 2021

Hello,

hello_imgui does not use exceptions and does not make any assumptions about them being present or not. So I guess you can do whatever you like.

I consider it as a kind of window management system for Imgui that hides some its mechanics

Yes.

P.S. It would be worth to mention about thread safety/awareness too.

hello_imgui does not launch any thread at all.

@MichaelKv
Copy link
Author

MichaelKv commented Apr 29, 2021

Thanks. To be able to use exceptions (and C++ does use them by default itself) or threads I must be sure the environment allows it. Imgui is almost a plane C library that does nothing about such support but it allows access to all the internals and do not have (or do not have many) callbacks that may throw. But as far as hello_imgui hides some internals and is built around the users’ callbacks (as I see from hello_world example) it shall provide exception safe guarantees or be aware about exceptions (allow a user somehow handle them and make hello_imgui intact). The same is valid about thread safeness – you are either thread safe or aware about threads (i.e. you provide some synchronization primitives that your clients may use).
I do have to wrap some Imgui code with my own thread/exception safe wrappers and this is OK though it means Imgui may not be used in real-life applications as is. But hello_imgui is a kind of wrapper itself and to have a wrapper around a wrapper…

hello_imgui does not launch any thread at all.

I do understand it. But the real applications inevitably do and your clients must know what to expect and how use hello_imgui in multi-threaded environment with exceptions.
In other words, your clients have to decide whether to use hello_imgui or write their own window management system (as I believe all them do for pure Imgui). I am not an expert in GUI applications and it is hard for me to estimate such cases myself so I rely on documentation heavily.

@pthom
Copy link
Owner

pthom commented May 6, 2021

If you look at the API overview, you will see these callbacks:

image

And these functions:
image

What HelloImGui::Run() will do is simply:

The wording "callback" is thus perhaps not quite appropriate, but be assured that these callbacks are synchronous.

So in summary,

  • hello-imgui does not make any exception safety guarantee, not anymore than imgui. However it does not launch any exception.
  • If the code of the user provided callbacks may throw, then either (1) the user should add a catch clause in the callback that will catch them, or (2) HelloImGui::Run will throw them synchronously in the application main thread. Option (1) is of course the better choice.
  • hello-imgui guarantees that at any given time, only one thread will be active inside hello-imgui (and in fact it does not create any thread).
  • if callbacks need to access data that could be updated by a separate thread (for example a camera thread that would update a video image), the user is responsible to protect the access to this data (via mutex, atomics, ...)

@pthom pthom added the documentation Improvements or additions to documentation label May 6, 2021
@MichaelKv
Copy link
Author

Ok, thank you. I see that in case of an error I have to invent some program behavior that would not crash the program. I cannot just throw an exception and stop thinking about the broken frame anymore. I can wrap the Imgui’s begin/end C-style paradigm with my own exception safe helpers but hello_imgui looks different and I am not sure I could use it the same way.
I wonder if there is a window manager for Imgui for C++ (the full-featured C++ with exceptions, threads, co-routines in the future, etc.)

@pthom
Copy link
Owner

pthom commented May 8, 2021

I cannot just throw an exception and stop thinking about the broken frame

Well, the callbacks that you provide are supposed to be consisting of mainly only GUI code (I.e ImGui calls). The business code should belong elsewhere, as for any program where the GUI is separated from the rest. You could plug signals and slots between callbacks and your business code for example (using Qt or boost::signal)

@pthom pthom closed this as completed May 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

2 participants