That's great info. For what it's worth, my function that calls nuke.scriptClear
is not directly being called by nuke.executeInMainThread -- it's being called
as a result of thread.start_new_thread, which is how I saw it being done in
some examples in the documentation:
"""
import thread
def calls_script_clear():
nuke.tprint('calling nuke.scriptClear')
nuke.scriptClear()
return True
def thread_dispatch():
return nuke.executeInMainThreadWithResult(calls_script_clear, ())
def button_callback():
""" run this on a button knob """
thread.start_new_thread(thread_dispatch, ())
button_callback()
"""
When it's done this way, Nuke doesn't crash. Check it out (don't run this in a
script you care about, it will clear it):
set cut_paste_input [stack 0]
version 6.3 v5
push $cut_paste_input
NoOp {
name notcrashy
selected true
xpos -78
ypos -96
addUserKnob {20 User}
addUserKnob {22 segfault T "import thread\ndef
calls_script_clear():\n\tnuke.tprint('calling
nuke.scriptClear')\n\tnuke.scriptClear()\n\t\n\treturn True\n\ndef
thread_dispatch():\n\treturn
nuke.executeInMainThreadWithResult(calls_script_clear, ())\n\ndef
button_callback():\n\t\"\"\" run this on a button knob
\"\"\"\n\tthread.start_new_thread(thread_dispatch, ())\n\nbutton_callback()\n"
+STARTLINE}
}
On Jan 10, 2012, at 5:10 PM, Ben Dickson wrote:
> The general a good rule of thumb is, if you make a method call from a
> thread, and it changes anything in the UI, should be executed via
> executeInMainThread
>
> ..but callbacks should all be executed in the main thread, so this
> should be unecessary (e.g try "import time; time.sleep(2)" in a PyScript
> button - it locks up the UI)
>
> This is definitely a bug:
>
> set cut_paste_input [stack 0]
> version 6.3 v5
> push $cut_paste_input
> NoOp {
> name crashy
> addUserKnob {20 User}
> addUserKnob {22 segfault T nuke.scriptClear() +STARTLINE}
> }
>
> ..but doing nuke.executeInMainThread(nuke.scriptClear) crashes
> identically for me
>
> A bit unrelated, but you don't need to use executeInMainThread for
> PyQt/PySide stuff any more, I guess since they now share an event-loop,
> instead PyQt running in it's own event loop in another thread(?):
>
> http://docs.thefoundry.co.uk/nuke/63/pythondevguide/custom_panels.html#migrating-from-qt-applications-nuke-6-2
>
> On 11/01/12 08:17, Alex Schworer wrote:
>> Howdy --
>>
>> I have fairly complex piece of code that, when run as a result of a button
>> callback on a gizmo will cause a segfault in Nuke. If I wrap that code in a
>> call to executeInMainThread, it runs fine. Also, I can run the code in the
>> script editor without a segfault. I've narrowed down the segfault to a part
>> in the code where I call:
>> nuke.scriptClear()
>> nuke.scriptOpen(new_script_path)
>>
>> So, my question is this: are there a set of rules or guidelines to follow
>> that tell us when we should wrap our code in an executeInMainThread? I don't
>> want to just start blindly wrapping stuff that fails in executeInMainThread
>> without knowing why I'm doing it. I've done a bit of googling, and see that
>> it was mandatory to run PyQt apps in a separate thread and use
>> executeInMainThread, but no guidelines that are more general than that.
>>
>> Cheers
>> --alex_______________________________________________
>> Nuke-python mailing list
>> [email protected], http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>
> --
> ben dickson
> 2D TD | [email protected]
> rising sun pictures | www.rsp.com.au
> _______________________________________________
> Nuke-python mailing list
> [email protected], http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
_______________________________________________
Nuke-python mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
