CefInitialize hangs when CefApp parameter isn't null

[magreenblatt]

Can you attach a debugger and break when CefInitialize is hanging, to see where it got stuck?

[cybersight]

Okay, I talked to one of the Dolphin developer and I think I know what's happening.

If I call CefInitialize with multi_threaded_message_loop enabled, the callbacks triggered by CEF from the main thread make it to my application, but any callbacks made on non-main threads don't. The reason for this is that in order to receive callbacks from non-main threads, Dolphin's message loop needs to be running, and it blocks while waiting for CefInitialize to return. Hence the hang.

Is it possible to somehow defer the callbacks made on non-main threads until after CefInitialize returns? Or is my only option to use CefDoMessageLoopWork or CefRunMessageLoop?

Also, the call to CefInitialize doesn't hang if I run it on a background thread. However, this goes against CEF's instructions to only call CefInitialize on the main thread. But is it actually an issue if I'm using the multi-threaded message loop?

Can you attach a debugger and break when CefInitialize is hanging, to see where it got stuck?

I haven't tried that yet. I do have a VS solution set up as per the instructions in cef-project, but that's just for my subprocess executable. Are there any instructions on how to run CEF itself under a debugger?

[magreenblatt]

The reason for this is that in order to receive callbacks from non-main threads, Dolphin's message loop needs to be running, and it blocks while waiting for CefInitialize to return.

I don't know anything about Dolphin specifically, but it seems strange that Dolphin's message loop would be required for threads initialized/started by CEF or Chromium. Or do you mean callbacks in Smalltalk code and not C/C++ code?

[cybersight]

The reason for this is that in order to receive callbacks from non-main threads, Dolphin's message loop needs to be running, and it blocks while waiting for CefInitialize to return.

I don't know anything about Dolphin specifically, but it seems strange that Dolphin's message loop would be required for threads initialized/started by CEF or Chromium. Or do you mean callbacks in Smalltalk code and not C/C++ code?

I mean, when the threads started by CEF/Chromium invoke callbacks to Smalltalk code. If it happens on a non-main thread, the callback needs to be marshalled back to the main thread, which requires going through Dolphin's message loop.

I think the reason for this weird behavior is that Dolphin's VM is not actually multi-threaded, which might explain a lot of the problems I've been having. And given the highly multi-threaded nature of CEF, the advice of the Dolphin developer was to create a higher level abstraction in C/C++ for Smalltalk to use instead. But I don't have a very good idea of what that would look like.

Do you know if any other language bindings have pursued that route?

[magreenblatt]

The think the reason for this weird behavior is that Dolphin's VM is not actually multi-threaded, which might explain a lot of the problems I've been having.

That makes sense.

the advice of the Dolphin developer was to create a higher level abstraction in C/C++ for Smalltalk to use instead. But I don't have a very good idea of what that would look like.

It might (for example) marshal all calls to the main smalltalk thread instead of calling directly into smalltalk from those threads. This should be fine for callbacks that have no completion or complete asynchronously. Anything that completes synchronously (e.g. needs to immediately return a value) will need some careful thinking/planning around.