• Re: TCL And Qt binding

    From Dave Thomas@21:1/5 to briang on Thu Aug 25 07:25:53 2022
    On Tuesday, July 6, 2021 at 5:48:29 PM UTC-4, briang wrote:
    On Tuesday, July 6, 2021 at 12:10:40 PM UTC-7, Petro Kazmirchuk wrote:
    In my company we have a complex C++/Qt/Tcl application, and a lot of effort was invested in integrating Tcl and Qt event loops. It was far from trivial, and still doesn't work reliably after 10+ years of polishing (and occasionally gets broken with
    Qt upgrades).
    Interesting. My experience was the opposite in that I found it fairly uncomplicated. I implemented a custom Qt/Tcl notifier to integrate the Qt and Tcl event loops. It's worked pretty much flawlessly and is still in use by my former employer. The
    tricky parts I discovered are these: 1) Tcl_DoOneEvent() has to be at the top of the QtApplication event loop. At least at the time I implemented this, Qt had no way to acknowledge the existence of other event queues, whereas, Tcl is designed with this
    concept. Letting Tcl control the event loop at the root, makes handling various end cases actually work. 2) Thread-enabled Tcl is required, and the custom notifier must be thread-aware. 3) I've seen what appears to be Tcl integration bugs actually turn
    out to be bad design; the application Qt code was poorly written in that it does not respect a proper Model/View/Controller pattern, and 4) consequently, the event loop code has to deal with recursion appropriately.

    https://ssl.webpack.de/www.eurotcl.eu/pastevents.html#eurotcl2019 https://youtu.be/1CRhEBzFjFc
    Instead of integrating Tcl interpreter in C++, I highly recommend to have a proper RPC framework to communicate between C++/Qt and Tcl in a separate process.
    That's one way to avoid problems :)
    Hi Brian,

    I found the presentation you made and the paper you wrote on Tcl/Qt event loop integration to very informative. I plan to go down that path and start the implementation in an existing Qt application.

    But, I didn't see anything in either paper about the requirement for "Thread-enabled Tcl" and "custom notifier must be thread-aware". Was that something you discovered after the paper and presentation? Can you elaborate on why threading is required and
    what that means to the notifier implementation (versus what's in the paper/presentation?)

    Thanks!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From briang@21:1/5 to Dave Thomas on Thu Aug 25 14:16:36 2022
    On Thursday, August 25, 2022 at 7:25:56 AM UTC-7, Dave Thomas wrote:
    On Tuesday, July 6, 2021 at 5:48:29 PM UTC-4, briang wrote:
    On Tuesday, July 6, 2021 at 12:10:40 PM UTC-7, Petro Kazmirchuk wrote:
    In my company we have a complex C++/Qt/Tcl application, and a lot of effort was invested in integrating Tcl and Qt event loops. It was far from trivial, and still doesn't work reliably after 10+ years of polishing (and occasionally gets broken with
    Qt upgrades).
    Interesting. My experience was the opposite in that I found it fairly uncomplicated. I implemented a custom Qt/Tcl notifier to integrate the Qt and Tcl event loops. It's worked pretty much flawlessly and is still in use by my former employer. The
    tricky parts I discovered are these: 1) Tcl_DoOneEvent() has to be at the top of the QtApplication event loop. At least at the time I implemented this, Qt had no way to acknowledge the existence of other event queues, whereas, Tcl is designed with this
    concept. Letting Tcl control the event loop at the root, makes handling various end cases actually work. 2) Thread-enabled Tcl is required, and the custom notifier must be thread-aware. 3) I've seen what appears to be Tcl integration bugs actually turn
    out to be bad design; the application Qt code was poorly written in that it does not respect a proper Model/View/Controller pattern, and 4) consequently, the event loop code has to deal with recursion appropriately.

    https://ssl.webpack.de/www.eurotcl.eu/pastevents.html#eurotcl2019 https://youtu.be/1CRhEBzFjFc
    Instead of integrating Tcl interpreter in C++, I highly recommend to have a proper RPC framework to communicate between C++/Qt and Tcl in a separate process.
    That's one way to avoid problems :)
    Hi Brian,

    I found the presentation you made and the paper you wrote on Tcl/Qt event loop integration to very informative. I plan to go down that path and start the implementation in an existing Qt application.

    But, I didn't see anything in either paper about the requirement for "Thread-enabled Tcl" and "custom notifier must be thread-aware". Was that something you discovered after the paper and presentation? Can you elaborate on why threading is required and
    what that means to the notifier implementation (versus what's in the paper/presentation?)

    Thanks!

    Hi Dave,

    For thread enabled Tcl, any common data, used with an interp, must be limited to a particular thread. Sharing data across threads must be done in a protected thread-safe manner. (Tcl has some API's to help with this.) Tcl maintains an isolated
    environment per thread for the interpreters. This is done by using hash table indexed by thread id for any common state for the thread. Each thread that has an interp, also has its own notifier. (possible confusion point: a slave interp is not the same
    as threads, and has nothing to do with threads.) Simply put, the notifier code has to be "aware" that there can be be multiple notifiers running concurrently, so memory access has to be handled carefully. This applies to any Tcl extensions, written in
    C, that has global state as well, not just the notifier. This is what is meant by "thread-aware".

    Unfortunately, I don't recall any details about Qt thread handling. It's been too long since I've looked at or touched any Qt code.

    Let me know if you have any questions.

    -Brian

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)