in reply to Re^2: Tk Bind scalar
in thread Tk Bind scalar

Oh... Threads? I don't know. The conventional wisdom is, or at least used to be, that synchronous event-driven systems (e.g. GUIs like Tk) and asynchronous threading models don't really play well together, since the problem spaces they attempt to address are nearly the same, yet they take entirely different approaches. Maybe you could consider using POE, which (I've heard) integrates very nicely with Tk (see POE::Loop::Tk). That would get you out of the realm of threads, which is even more messy in Perl than in some other popular languages.

Replies are listed 'Best First'.
Re^4: Tk Bind scalar
by zentara (Cardinal) on Feb 20, 2009 at 21:31 UTC
    If you take precautions, threads work fine in event-loop systems. As a matter of fact, in Glib, each thread can have its own independent loops.

    I'm not really a human, but I play one on earth My Petition to the Great Cosmic Conciousness
      in Glib, each thread can have its own independent loops.

      Sure. But having a bunch of threads share a single "global" event loop is rather harder. That's why it's preferable (imo) to get a module to manage the mess (e.g. POE), rather than trying to reinvent the wheel. :-)

        It's like in a fork...should changing scalars in a fork affect the parent? No. Same with threads. Communication channels....shared vars, filenos make the communication easier, but it is still up to the parent or sibling thread to actively read another thread......no forced broadcast allowed. You could set it up that way if you wanted. (Like a family yelling at one another :-))

        I'm not really a human, but I play one on earth My Petition to the Great Cosmic Conciousness