Threading and GUI freeze

   3387   5   0
User Avatar
Member
17 posts
Joined: 10月 2009
Offline
Hi everyone, this question concerns the HDK 10.

I have a SOP node where I run a simulation and I want the ability to pause the simulation from a GUI button in the interface.

In short I want to start the simulation on a separate thread so houdini could be alive and answering to input (the pause button).

My current approach is to create a UT_Thread and start the simulation function in that thread, however the thread is terminated when my buttons callback function returns:


static callback_function, called when “start simulation” button is pressed:

UT_ThreadSet myThread(1);
myThread.setFunc((void *(*)(void *))&cewl);
myThread.go();
return 1; // myThread is terminated here.


So, what I would like to do is some sort of wait:

UT_ThreadSet myThread(1);
myThread.setFunc((void *(*)(void *))&cewl);
myThread.go();
myThread.wait()
return 1;


But that does not work either because it will still freeze the GUI in houdini. Are there any ‘refresh gui’ - functions or something like that? Any other suggestions on how I should do this?
Portfolio / Tech. blog: http://www.theprocedure.se [theprocedure.se]
User Avatar
Member
229 posts
Joined: 5月 2006
Offline
Hi,

i guess what you try to do does not work as you want to do that.
The way houdin works in SOPs is that for each node the cookMe is called and than it uses the result to display, or further processing.

From the top of my head i think what you could try is some kind of communication with your simulation module
- outside Houdini solver you could use sockets to comunicate (start/stop/next frame) and the results
- or the solver as part of your node but since the cookMe is called only once per frame and with the inputs as “only-data” you have to somehow cache the results of the previous simulation step to simulate further


Seb
Edited by - 2009年11月10日 07:52:16
User Avatar
Member
17 posts
Joined: 10月 2009
Offline
Thank you for your fast reply!

The simulation is run when I press the ‘start’ button in the interface, the results are cached in memory (or disc) and fetched if available for the current frame when the CookMe() is called.

So the problem isn't really connected to cookMe(), but when I press the simulation button I don't want houdini to freeze.

I hope you can make sense of this
Portfolio / Tech. blog: http://www.theprocedure.se [theprocedure.se]
User Avatar
Member
229 posts
Joined: 5月 2006
Offline
humm,

i've never tried to do something like this, and to be honest, it feels weird .


On Button Press you create a thread & you start it.
but as you've realised it kills the thread object when it quits the ButtonPress Callback Thingy.
So maybe you have to make the myThread variable available to the whole class, since you need access to it if you want to stop the process.

Seb
User Avatar
Member
7868 posts
Joined: 7月 2005
Offline
mattis
I have a SOP node where I run a simulation and I want the ability to pause the simulation from a GUI button in the interface.

In short I want to start the simulation on a separate thread so houdini could be alive and answering to input (the pause button).

Your problem is that UT_ThreadSet will cancel all its threads when it's destructor is called. You can't just make it local stack data. It's probably easier to explicitly manage your own UT_Thread object.


// myThread should be a *class member*
// call delete myThread in your class destructor
myThread = UT_Thread::allocThread(UT_Thread::ThreadLowUsage);
// Run your function in a different thread
myThread->startThread(&threadfunc)


Make sure your thread function doesn't do anything to change Houdini's state since it's generally NOT thread safe.

The other issue will be how to communicate with your thread to pause/continue execution. If it's simulates in a loop, you can probably just communicate via SYS_AtomicInt32::exchange() and SYS_AtomicInt32::add(0) (see SYS_AtomicInt.h and SYS_AtomicIntImpl.h).
User Avatar
Member
17 posts
Joined: 10月 2009
Offline
Your problem is that UT_ThreadSet will cancel all its threads when it's destructor is called. You can't just make it local stack data. It's probably easier to explicitly manage your own UT_Thread object.

Actually I realized it yesterday when I was about to make another post about this ‘strange’ behavior. What a rookie mistake Sorry to bother you with this!

Thank you for the advice on thread communication, I will definitely look in to it!
And thank you Seb, for your time!
Portfolio / Tech. blog: http://www.theprocedure.se [theprocedure.se]
  • Quick Links