Update! I discovered that it is triggered by me hitting Save on a .py that I'm working on in a script editor which is also loaded. It only happens if I have the server up and running. So I'm guessing that somehow the thread/tornado combo is reading from the live .PY files rather than the .PYCs? Anyone have thoughts on this?
On Wed, Dec 9, 2015 at 11:03 AM, Den Serras <denserras...@gmail.com> wrote: > Hey all, > > I've got Tornado server running in a separate thread on Nuke 9.0v8 so we > can pass data to Nuke from our shot manager. It's working fine, except for > one thing: sometimes Nuke will launch a new instance by itself, loading > whatever comp I'm working on, and killing the thread that contained Tornado > (though not releasing the socket) in the first comp. I thought maybe it was > a Nuke or Python timeout but there doesn't seem to be any consistency as to > when it actually launches. > > I can't find anything about this happening on the Interwebs. Anyone have > any ideas? Here's the code I'm using to launch: > > def serverThreadStart(): > # Script which starts a new process (so Nuke doesn't hang while waiting > for data) to host the server > threading.Thread(target=serverStart, name="tornado").start() > vPrint(0,"Starting Server Thread at port 6075") > > > ### START SERVER > def serverStart(): > # Script which actually opens the port > # TODO: look for an open port before assigning it > URLs().application.listen(6075, "localhost") > tornado.ioloop.IOLoop.current().start() > > > I will test creating a separate process with Tornado or Python rather than > using Nuke's, and see if it will still talk to Nuke. Might not... > > Den >
_______________________________________________ Nuke-python mailing list Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
