C++ async await?

@einhugur @MonkeybreadSoftware
Have a question that might need a plugin of some kind to solve

I basically need to achieve something like “async await”

what I have is code in a thread that needs to synchronously run something on the main thread so it can read/write properties on controls

the UIUpdate event on a thread wont do what I want

thoughts ?

Can I even use C++ async in a Xojo plugin ?

It can be done…

But its complicated and has severe limitations.

Its basically what the TypeLib’s Task class is doing it has WaitFor method which is your await in C# terms.

But as I said it is complicated and has severe limitations. Cannot run anything at all from Xojo there in the green zone. (Especially not anything that creates object, releases object or references or de-referencs)

that should be written not in Xojo but in c++, c#, java…jo. I would write in java I guess Einhugur would write in C or C++ or C#…but Xojo?

If wanting to make this more useful in Xojo and closer to reality for like normal user then this one here would need big push from someone or something that has substantial influence on Xojo.


Until that journey starts then waiting for big task in Xojo will always be sluggish and flawed. :frowning:

Apart from the very few cases where the Above TypeLib RuntimeTask can work and Christian might have similar few cases also.

these are NOT options in this case

otherwise I would

you can always just use Timer.CallLater to run something on the main thread.

call later doesnt do what I need

it needs to be like an ASYNC AWAIT

behave synchronously even if its async

CallLater doesnt do that

CallLater, Xojo “Thread”…Timer…all makes UI sluggish in big tasks since those are not real threading ways by any means.

yeah I just need a way to, from a thread, run something on the main thread but I need it to be synchronous as the method I call MAY return a value

Call later or short period timers dont give me that assurance

Hence why I stay I need something like async await

I don’t know of a way to do async processing in C# or C++ that would have any awareness of a Xojo structure that it could update.

Have you considered using a Xojo worker and having it return some sort of struct you could decode, or have it just write a bunch of key/value pairs to a text file you could read? It would be ugly / fragile but if I properly understand what you want to do, I think that might fit the bill.

yeah a worked wouldn’t cut it since this needs access to the UI thats present :frowning:

I was thinking in crufty terms like:

  1. Gather the info from the UI into some sort of structure or formatted text
  2. Pass it to the worker
  3. Get the changed info back at some later point when the worker is done and the main thread is ready / needs to deal with it.
  4. Put the returned info into the UI

Obviously you have the extra overhead of (dis)assembling this data passing structure but one could probably make it somewhat generic (name of control, key/value pairs for desired info).

If you want to have the async task examine the UI and make changes to it, I don’t see how you’d do it safely and without epic amounts of reverse engineering unless Xojo exposes an API for an external process to walk through the Xojo object graph AND make changes to it. Which I’m guessing they do not.

Yeah I dont think a worker will work here because of the required access to the UI
Serializing the entire UI to send to a worker just wont be feasible and still has the issue of it NOT being synchronous like async await :frowning:

I need a way to punt a method call into the main thread synchronously - Timer.CallLater can “sort of” do this but the issue is I get the returned value AFTER I need it

Which is where something like async await would be nice since that will run an async task, possibly on the main thread, and wait until that has completed

But Xojo doesnt have async await so I’m trying to figure out how I might fake that - with or without a plugin or lord knows what else

could you calc in a thread what has not to be in the timer and set a flag when return value is calculated? nThen you would come around and ´do the rest in a timer to mnipulate the ui?

If you just need to read UI control properties couldn’t you do something with property shadowing to push a copy of the control properties into something the thread can read safely?

thats sort of what I’ve been trying so far
its just messy as hell :stuck_out_tongue:

Problem is I cant tell WHAT I might need without analyzing all the code
THAT could be really onerous as some will be in XojoScripts and some not :frowning:

Dont get me wrong I like all the ideas as I’m sure something can work
I just haven’t found it

Not totally clear what you’re trying to do (“… as some will be in Xojoscripts and some not…”), but as a strawman:

  1. In the thread, call a local proxy function for the one you want to call on main
  2. In the proxy, set parameters on the thread class (or, if we want to be really generic, serialize parameters into some structure… this is where what you’re doing isn’t clear to me as far as how generic this needs to be – example would be helpful)
  3. Append a flag, indicator or pointer referring to the thing you want to call in an array on the main thread (again, this could be simple for a single call case, or super generic if you need it to work with anything). You’ll also need a reference to the calling thread here, as well
  4. Call pause on the thread → context switches while stopped in the proxy function
  5. On main, you’ll need a timer to examine the array of call references and dispatch the function you want (again, could be a single thing or something more involved to handle the generic case… examples?)
  6. In the function on main, if you need to return something, use the reference to the calling thread to write it to a proxy variable there (there are other ways to manage this, of course)
  7. Resume the calling thread(s) at the end of the timer run (and clear the dispatch array)
  8. Thread resumes in the local proxy function. Grab the value “returned” from main and return it from the proxy function. From the thread’s perspective, the function on main has been called synchronously.

Yeah this is a lot like what a future would do ( in C# its compiler magic that takes it and turns it in to a finite state machine that blocks the original call into the code until the function called returns)

Let me see if my little example demonstrates my conundrum well enough and then I’ll post it