Nice!
Will the call performance continue approaching the QT signal-slot architecture or do you think you are already there?
It's much closer. Google says QT signal/slots are about 10x slower than a C++ virtual method call. Virtual calls are about 2-3x slower than a direct call. Meaning slots are 20-30x slower than a direct call.
That means a Sigils call is probably about 2-3x slower than calling a QT slot. Without actually testing it I can't be sure.
For local calls Sigils should be able to be sped up to match QT. Currently all parameters are packed into a ref object which incurs extra overhead and is not needed for local calls.
Support for local queued calls has been added with connectQueued! It's part of the threading module, but doesn't require a separate. It builds on the event loop and queue used for threading support though.
It's similar to "run soon" in async. Made it really easy to solve a work problem where I wanted a thread to do some work downloading data in batches or when triggered by new work.
I also had GPT-5 write docs for how the threading support works but the result is t the best. Still probably better than nothing.