We have a good example of a Sketchup C Extension to build on, made by @thomthom here:
I am developing an extension building on this model, and I would like to go one further. Instead of Ruby calling the C extension and waiting for the C program to complete, I would like Ruby to call the C extension, and continue about its business, and the C extension to call Ruby again when it has completed its job. I understand that this is referred to as an ‘asynchronous’ function call.
I know that Skalp (@Guy ? ) must do something like this. There has also been some discussion here about using the ViewObserver object to periodically check after calling Sketchup.send_action(), but I am not sure this is ideal.
Asynchronous calls also work in the WindowDialog, but again, that seems hacky to me.
Are there any examples out there for asynchronous calls to C?
What would the C side of things be doing? Would it be interacting with the active model? If so - then how would you handle operations etc? (If the C side complete several seconds later and the user continued doing other things?)
Would be good to have examples of what a “job” is.
That aside, I would avoid anything related to Ruby threads - they don’t work well inside of SketchUp.
Also, note that you can’t expect to read/write from the active model from another thread. The API is not thread safe.
This is, as I understand it, the idea of asynchronous calls. My extension would, on the Ruby side, observe what the user is doing with some geometry, and at certain events, would collect the geometry in that context, export it as a skp file, and call the C side extension to start processing it. Ideally, the user carries on doing their thing while the processing goes on. When the C process is finished, I want SU Ruby to somehow ‘know’, and import a skp file that that C process has output.
Basically, that is the gist of it.
If SketchUp doesn’t work with threads, how do the observers in the API work? Or perhaps you are saying don’t try to do any custom multi thread stuff?
Perhaps hacking the ViewObserver is the way to go?
Don’t expect to be able to work on the active model in any thread other than the main one.
If you export a .SKP files then you could work on that in a separate native thread - but you’ll face a challenge on what to do when it’s done. You’d need some kind of polling in the main thread to query whether it’s done or not.
Once you have solved that - you have the question of, what if that thread is done when the user is busy with a tool? Doesn’t sound good to suddenly jump in and make model changes then - it’ll most likely cancel the current tool state.
If the geometry being updated is not the geometry that the user is currently editing, then the user experience should work out ok.
Generally, I understand all of the potential pitfalls you are mentioning. I should really ask the guys at Skalp how they do it, as it is clear from their plugin that their C-side is asynchronous with Sketchup Ruby.
If you use Skalp, you’d notice that the section cut gets updated after you edit some geometry. With larger models, you’d see that there is a delay between making the edit and the section cut being updated. During that delay, the user is able to do other things, and does not have to wait.
I have a sneaking suspicion that they use the asynchronous calls that you can make on webdialogs and Javascript.
And I think this is probably the most realistic approach. Either a timer to check for a file in a specific location that the C-side creates/manipulates, or hacking an API observer of some sort (ViewObserver being a good candidate) to check for the file.
In any case, I hoped someone might have tackled this question at some point.