Deadlock in VST host application
-
- KVRist
- Topic Starter
- 90 posts since 24 Mar, 2011
I posted a question for VST developers at https://stackoverflow.com/questions/583 ... pplication in case anyone knows the answer. If you don't have an account at stackoverflow.com, please post your answer here. Thank you.
-
- KVRAF
- 7890 posts since 12 Feb, 2006 from Helsinki, Finland
Trying to run different windows in different threads is a "recipe for pain" in general, so my first suggestion would be to rethink your application design.
That said, if the problem is with modal dialogs in particular, it might have something to do with modal message loops. Specifically, when you call something like MessageBox that call doesn't return before the modal popup is dismissed, so your application message loop doesn't run while the dialog is open. Since the dialog itself still needs a message loop to function though (and to handle repaints for the application window below, etc), what happens is that the modal dialog itself calls a special modal message loop.
What this means in practice is that if your application relies on being able to intercept custom messages directly from the message loop itself, it is never going to work properly in the presence of modal loops, because you can't control what those loops do and therefore they won't be processing your special messages correctly.
That said, if the problem is with modal dialogs in particular, it might have something to do with modal message loops. Specifically, when you call something like MessageBox that call doesn't return before the modal popup is dismissed, so your application message loop doesn't run while the dialog is open. Since the dialog itself still needs a message loop to function though (and to handle repaints for the application window below, etc), what happens is that the modal dialog itself calls a special modal message loop.
What this means in practice is that if your application relies on being able to intercept custom messages directly from the message loop itself, it is never going to work properly in the presence of modal loops, because you can't control what those loops do and therefore they won't be processing your special messages correctly.
-
- KVRist
- Topic Starter
- 90 posts since 24 Mar, 2011
You're probably right that trying to run different windows in different threads is a "recipe for pain" in general.
And, in the meantime, fortunately, I was able to resolve the issue (in that direction).
And, in the meantime, fortunately, I was able to resolve the issue (in that direction).
-
- KVRAF
- 7890 posts since 12 Feb, 2006 from Helsinki, Finland
Since you keep repeating that you have a custom GUI that doesn't use native APIs (which is obviously not strictly true, because at some point you do need to use native APIs to have any sort of GUI), I have to ask: are you absolutely sure that somewhere inside whatever library you might be using, there isn't a standard message loop (or something close enough) capable of dispatching messages to the plugin windows?
I'm aware that some game oriented libraries do some really weird stuff (eg. SDL intercepting mouse/key input in PumpEvents directly on macOS), but for any "normal" toolkit (ie. basically anything that's supposed to handle multiple windows) I would expect a separate message loop to be unnecessary on both Windows and macOS, even if the actual message loop is buried somewhere deep inside some library.
I'm aware that some game oriented libraries do some really weird stuff (eg. SDL intercepting mouse/key input in PumpEvents directly on macOS), but for any "normal" toolkit (ie. basically anything that's supposed to handle multiple windows) I would expect a separate message loop to be unnecessary on both Windows and macOS, even if the actual message loop is buried somewhere deep inside some library.
