This locks up Maya.
from maya import utils
def nested_func():
print "Hello world"
def func():
utils.executeInMainThreadWithResult(nested_func)
utils.executeInMainThreadWithResult(func)
Though I can currently work around it, I can’t quite understand why it
would lock up.
--
*Marcus Ott
Hey Marcus,
Maybe it's like nuke's similar command, that is only meant to be used
inside other threads, and not the main one...
Just thinking out loud...
Cheers!
Eduardo
On Fri, Nov 21, 2014 at 9:02 AM, Marcus Ottosson
wrote:
> This locks up Maya.
>
> from maya import utils
> def nested_func()
That would have been acceptable, but it actually locks Maya up when used
from within a thread as well. Seems no matter how I twist and turn, that
call called from within another call locks Maya up.
On 21 November 2014 12:46, Eduardo Grana wrote:
> Hey Marcus,
>
> Maybe it's like nuke's similar c
Could it be that the inner call is waiting for the outer call to finish,
before it can start? And because it never starts, the outer call is never
finished?
On 21 November 2014 14:06, Marcus Ottosson wrote:
> That would have been acceptable, but it actually locks Maya up when used
> from within
"The script or callable object is executed in the main thread during the
next idle event. The thread callingexecuteInMainThreadWithResult() blocks
until the main thread becomes idle and runs the code. Once the main thread
is done executing the code, executeInMainThreadWithResult() returns the
Thanks, Robert. Makes sense now.
Which is why this does work if you just use executeDeferred(), which
doesn’t block in the same way.
Do you have experience with this across threads? Since it doesn’t return
anything it’s a little tricky as a replacement, but if it’s thread-safe
then I’ll certainly
I've had good luck with it for simple tasks like updating GUIs.
I also use it as part of my startup sequence for any tasks that need to
build/tweak/change maya's default GUIs, because not enough of the maya
environment is loaded during userSetup.py's execution. But if you defer
those tasks, the
I’ve had good luck with it for simple tasks like updating GUIs.
Ah, are you then also calling executeDeferred() from a separate thread,
without first wrapping it into a executeInMainThreadWithResult?
On 21 November 2014 at 16:39, Robert White
wrote:
> I've had good luck with it for simple tas
I did a quick scan of my codebase and while I know I used it in the past it
looks like I'm no longer using executeInMainthreadWithResult anywhere.
So it looks like I've been surviving on just doing executeDeferred.
And the major places that I am triggering it all seem to fall into a few
scenar
