I think it should be ok based on some other posts I’ve read and the lack of a single GUI thread like there is in vision. Can someone more knowledgeable than me confirm that?
Is there a dev who could weigh in on this?
The same warning, regarding single threaded access to the GUI, doesn’t apply, since every script in Perspective is running on the gateway and has to communicate back to the session, which automatically gets put into a queue to be single threaded.
There is a different tradeoff - invokeAsynchronous is making high-level Java threads, which can be expensive. Especially since every Perspective session’s backend is inside the gateway JVM, running many ‘delayed’ tasks x many Perspective sessions could rapidly scale up to a significant hit on the gateway.
I believe @pturmel’s ‘later.py’ (somewhere on these forums) uses an internal gateway mechanism to ‘schedule’ tasks with a delay on the gateway without the penalty of creating an entire thread. That’s probably a much ‘safer’ way to go.
Does this include writes to session/page/view properties whose base objects were handed off to the asynchronous thread? (via closure, or partial(), or default args) I haven't dug under the hood to see how the queue works, yet.
Also, I don't think the OP is asking about delayed execution, per se.
I didn’t ask about delayed execution by name, but @PGriffith guessed correctly that that’s where I was going. I’ll look into later.py for the delayed functions. It’s good to know that invokeAsynchronous is an option for other things though.
Yes - the 'wrapper' objects that are exposed to scripting, as well as the Perspective scripting functions, all follow a pattern of queue().runOrSubmit(Runnable) - there's also guards in place on actual implementations (eg, property trees) to ensure the caller is the queue.
Hah! I guess this means you cannot read back a property just written and expect to see the new value. That will break some skulls along the way. (Very non-pythonic…)
Is there any way to perform multiple updates as a single queue runnable? Essentially making it a transaction?
Well, we went to some trouble with property trees in particular so that you’ll have a copy ‘in memory’ that syncs with the “real” copy, even as you do updates.
Also, if you have a large batch of updates to do, each Perspective element overrides __setattr__, so if you do something like session.custom = aDictionary it’ll attempt to perform that update as a single operation, specifically by merging (and pruning orphaned keys on the original) the two nested structures.
