Changing the definition of DSOInit is certainly wrong - it is part of the RenderMan shader interface and should remain binary-compatible with that.
There's a copy of the DSO interface documentation at <http://graphics.stanford.edu/lab/soft/purgatory/prman/Toolkit/dsoshadeops.html>. This says that the first parameter to initialisation functions is some kind of thread identifier. I don't see that this can mean an OS thread id, since the DSO can find that out itself. I think it's only necessary that at any given time each instance of CqShaderVM has a distinct id to pass to DSO initialisation functions. So the current code looks OK on platforms with 32-bit pointers (instance addresses being obviously unique), and Andreas's patch would make it work with 64-bit pointers *almost* all the time. Assigning 32-bit serial numbers to CqShaderVM instances might be more reliable, but still leaves the theoretical possibility of collisions. Off-hand, I can't think of a method of assigning such identifiers that's both correct and efficient, though I'm sure such methods exist. However - I now notice that CqShaderVM::Clone copies the whole object, including information about initialised DSOs, which means that there can be multiple CqShaderVM instances sharing ids. I really don't know what Aqsis is playing at. I think this needs some attention from upstream. Ben. -- Ben Hutchings Humans are not rational beings; they are rationalising beings.
signature.asc
Description: This is a digitally signed message part
