Hey Vincent, multithreading is different of multiprocessing... short long story, multithreading is about running many threads in the same memory space (so shared memory and so use of patterns such as mutex, semaphore,...) while multiprocessing is about running different external processes (all having their own memory space)... It becomes tedious when you want to share data then across those different processes as they don't share a common memory space, Python designers achieve this by simply pickling the datas you want to share (and so you have to be sure they are pickable) and saving them somewhere in memory or on disk (where processes known where to look for). multiprocessing is a powerful concept equivalent in theory to pipes or even co-routines. As Matt said, the sdk is not thread-safe, so forgetting about multithreading is a good rule to follow, while I wouldnt even think about multiprocessing to access scene graph components. To boost your operator, review and be sure your code is optimized (thats just all what it takes 90% of the cases) ! if this is still too slow, move to Cpp... --jon
2013/5/30 Matt Lind <ml...@carbinestudios.com> > Outside of ICE, the SDK is not thread safe. > > Matt > > > -----Original Message----- > From: softimage-boun...@listproc.autodesk.com [mailto: > softimage-boun...@listproc.autodesk.com] On Behalf Of Vincent Ullmann > Sent: Thursday, May 30, 2013 3:43 PM > To: softimage@listproc.autodesk.com > Subject: Re: Python Multiprocessing in Softimage > > Hmm... ok, thanks > > Is it possible to write a multiThreaded CustomOperator in C++ ? > I already build a simpler version of my ScriptedOp in C, so i might "just" > make it multiThreaded.... ;-) But first it would be nice to know if > Softimage could handle this > > > Am 31.05.2013 00:36, schrieb Matt Lind: > > Outside of ICE, the SDK is not thread safe. > > > > Matt > > >
