Hi,

I have a thread that I wish to change some data that my custom LOP will then use to generate its USD content from, and I wanted to check if i'm doing this right as I can get exceptions thrown as well as a crash - so something is not right!

My LOP has some data structures (straight struct's basically) that I change on another thread.
1) I cache the "working lop" path via the main thread and the pNode->getFullPath() call
2) On the worker thread I use this path via OPgetDirector()->findNode(pathLop) to get the LOP instance
3) On this worker thread I then set the struct data for the LOP ready for its next cook.
4) Once set, I call forceRecook() on the LOP pointer in the thread to indicate it needs recooking.

From the bottom up, is the forceRecook() call the one to make to flag that the LOP needs recooking? I can get exceptions thrown of they the type "std::out_of_range at memory location" in the python calls that occur from within this call. These do not cause a crash, but it makes me suspicious that this might not the call to make from another thread. In case this is important, the forceRecook can be called more than once on the worker thread before the main thread picks up the change and calls cookMyLop at a later date.

Occasionally I get a null pointer crash on the main thread in libUI.dll!UI_Queue::processNextEvent() Line 2025 whereby UI_Queue::UI_ActualQueue::remove() returns a nullptr. This is terminal so i'm certainly breaking this one.


I tried adding UT_Lock's in both threads around changing the data (in case that was causing issues) but it made no difference to the crashes and exceptions occuring.

My code is based on the sample sphere lop in terms of how I generates the USD and i'm working under Windows (compiled with the v143 toolset) and H20.0.625.

If anyone can help/point me in the right direction for this it would be greatly appreciated!

- Simon

It might be more complicated than this, but if you're lucky, and you are creating your worker thread the right way, you might get away with just creating a HOM_AutoLock object scoped around your worker thread's code that modifies your LOP node. The HOM_AutoLock class is defined in HOM/HOM_Module.h, and is basically the "global" flag in Houdini that says "nobody should be modifying any nodes in any way unless they hold this lock".

The general approach of calling forceRecook after updating the internal data structures is, I think, correct.

That's the one - rather than using a UT_Lock to manage access to the LOP of my operations, it instead needed the HOM_AutoLock so that
nobody else went near it whilst it was changed/cooked. It does make we worry that it must be quite an "expensive" lock to be taking mind!