Thanks I'll give that a go...
On Thu, Mar 10, 2011 at 4:53 PM, Jonathan Egstad <[email protected]>wrote:
> I've had no crashing problems with separate threads at the C++ plugin
> level. If you use the built-in DDImage threading support it should work:
>
>
> static void server_callback(unsigned index, unsigned threads, void* p) {
> static_cast<MyIop*>(p)->check_server();
> }
>
> void MyIop::check_server() {
> // talk to renderer, get pixels, call update(), delay;
> }
>
> void MyIop::_validate(for_real) {
> ...
> ...
> if (m_interactive && DD::Image::Application::gui && m_server_status <
> SERVER_LISTENING) {
> m_lock.lock();
> if (m_server_status < SERVER_LISTENING) {
> Thread::spawn(server_callback, 1, this);
> m_thread = Thread::thisThread();
> }
> m_lock.unlock();
> }
> }
>
> -jonathan
>
> On Mar 9, 2011, at 9:37 AM, anders langlands wrote:
>
> > I never found a way to update the buffer properly from a separate thread
> without nuke crashing. In the end we just added a button to call
> asapUpdate() from the main thread. It's stable, and it gives TDs something
> to do while they're waiting for renders.
> >
> > On Wed, Mar 9, 2011 at 5:30 PM, Nicolas DUMAY <[email protected]> wrote:
> > Hi all,
> >
> > I'm working on a Iop that take his infos ( the pixels ) from an
> > external renderer.
> > My Iop have an internal buffer that I fill with rendered buckets and
> > the engine function simply display that buffer.
> > I'd like to call ASAPUpdate when a bucket ended but that lead to too
> > much call in a few moment and nuke badly segfault. Any idea or
> > workaround?
> >
> > Nicolas
> >
> > Ps: I already try to put a usleep of 0.1 sec before calling ASAPUpdate
> > but this slow my render on simple scene and I'm not sure it's the best
> > way of doing it...
> >
> > Envoyé de mon iPhone
> > _______________________________________________
> > Nuke-dev mailing list
> > [email protected]
> > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
> >
> > _______________________________________________
> > Nuke-dev mailing list
> > [email protected]
> > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
>
> _______________________________________________
> Nuke-dev mailing list
> [email protected]
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
>
_______________________________________________
Nuke-dev mailing list
[email protected]
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
