|
|||
I'll have a look at this, but the real problem is not the vector itself, but the data stored in the vector and the posibility of having invalid pointers being accessed by the audio thread. After having considered for a few hours I think reference counting is the best solution for this problem, and considering the way I've implemented my classes it should be fairly easy to add that feature to my objects. |
|||
| ^ | Joined: 11 Feb 2009 Member: #200706 Location: Perú | ||
|
|||
You can update the tree in your blockManager::process at the beginning. So only what you need its a fifo for insert update and delete actions. In the guiThread
you insert the modifications in the fifo and in your blockManager::process funktion you trigering the actions so long the fifo its not empty. After this you must notify the guithread to redraw. |
|||
| ^ | Joined: 09 Jun 2004 Member: #28896 | ||
|
|||
Update:
The job was finally done using what zman suggested: using a FiFo to queue insert and delete actions, and updating the tree at the beginning of blockManager::process only if there's anything in the FiFo. I also implemented Reference Counting to better manage the lifetime of my objects, specially those running scripts that could be still working when the user deletes the correspondig object. Since the script holds a reference to the object calling it, the object is only gone once the script returns (with its task completed or interrupted). Thanks for all your answers. |
|||
| ^ | Joined: 11 Feb 2009 Member: #200706 Location: Perú | ||
|
|||
| ^ | Joined: 07 Dec 2004 Member: #50793 | ||
|
|||
Tzarls wrote: a FiFo to queue insert and delete actions, and updating the tree at the beginning of blockManager::process
This is exactly the approach used in DSP Filters: Thread queue: https://github.com/vinniefalco/DSPFilters/blob/master/shared /DSPFiltersDemo/source/ThreadQueue.h |
|||
| ^ | Joined: 30 Nov 2008 Member: #194779 | ||
|
|||
Tzarls wrote: I also implemented Reference Counting to better manage the lifetime of my objects, specially those running scripts that could be still working when the user deletes the correspondig object. Since the script holds a reference to the object calling it, the object is only gone once the script returns (with its task completed or interrupted). I went a little further an implemented 'handles', so rather than holding a pointer to an object (that might get deleted at any time), the GUI and corresponding DSP objects hold the same handle (a simple unique integer number). So the GUI can put a message in the FIFO addressed with it's handle, the DSP side then looks up that object based on the handle. |
|||
| ^ | Joined: 30 Jan 2005 Member: #56398 Location: New Zealand | ||
|
|||
Jeff McClintock wrote: I went a little further an implemented 'handles', so rather than holding a pointer to an object (that might get deleted at any time), the GUI and corresponding DSP objects hold the same handle (a simple unique integer number).
That means your FIFO is not generic. Consider instead, the use of a FIFO that accepts arbitrary functors (see DSPFilters ThreadQueue.h for a working example). You can use boost::bind, std::bind, or std::tr1::bind (depending on your environment). Instead of a straight pointer, use boost::shared_ptr, std::shared_ptr, or std::tr1::shared_ptr, or juce::ReferenceCountedObjectPtr<> and you will get all of the benefits and safety of reference counting without the need of your own integer descriptor / handle system. |
|||
| ^ | Joined: 30 Nov 2008 Member: #194779 |
| KVR Forum Index » DSP and Plug-in Development | All times are GMT - 8 Hours |
|
Printable version |
Disclaimer: All communications made available as part of this forum and any opinions, advice, statements, views or other information expressed in this forum are solely provided by, and the responsibility of, the person posting such communication and not of kvraudio.com (unless kvraudio.com is specifically identified as the author of the communication).
Powered by phpBB © phpBB Group















