in reply to Re^4: bidirectional pipe freezing
in thread bidirectional pipe freezing

With this approach (at least on my platform) you don't even need require. You can go ahead and use Tk.

Indeed, it works fine like that. The only downside is that your threads will 'inherit' various bits of Tk code and data that they cannot use.

Whilst the additional memory consumed is insignificant unless you are really pushing the boundaries of your system, the fact that the Tk::* name space is visible within your threads can lead to the temptation to try and use it.

What is worse is that sometimes, some calls will actually seem to work. Until they stop -- usually by crashing -- that is :)

I like the discipline, and removal of temptation, that requireing Tk after I've set up my workers brings. The only downside I see is that you have then to use Tk::MainWindow->new(); and Tk::Mainloop() etc. It is even possible to bypass that by an appropriate call to Tk->import (Or is it Tk::import;?), but I never seem to get that right first time.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

Replies are listed 'Best First'.
Re^6: bidirectional pipe freezing
by chessgui (Scribe) on Dec 21, 2011 at 21:13 UTC
    You seem to be very deeply into perl. Indeed my knowledge of perl is very shallow. First I've tried to develop my app in Visual C++ where I have full and uncompromising control over my Windows system.

    Yet, implementing simple ideas in C++ can get ridiculously complicated. I'm not interested in coding itself but to get my ideas through as simply as possible.

    In perl some 30 characters are enough to generate a window: "use Tk;new MainWindow;MainLoop;" while in C++ you need some 30 _lines_ for the same.

    I'm only interested in your opinion whether PROVIDED that I'm not tempted to use Tk functions in my working thread is it GUARANTEED that my code is safe?
[reply]
      PROVIDED that I'm not tempted to use Tk functions in my working thread is it GUARANTEED that my code is safe?

      Safe from what? I'll assume you mean: safe from problems arising as a result of using Tk in a threaded program.

      Think of it this way. Every program that uses Tk is a threaded application. It may only have one thread, but it is still threaded.

      Indeed -- certainly in Windows, and arguably in other OSs too, though I am very vague of their internals -- the fundamental unit of processing is the thread. It is threads that are scheduled by the scheduler, not processes.

      So, if you take a single-threaded Tk app and start another thread that does nothing but sleep, will that bring the house down? I think you;d have to agree, probably not.

      So what if instead of just sleeping, that thread loops around? Still probably safe. So what if it does lots of things: reads and write from disk; communicates via sockets; allocates big chunks of ram; and does billions of calculations; will that cause Tk to fall over? Again, my given understanding of iThreads is that because no memory is shared between threads unless you explicitly request for it to be so, there should be no interactions between threads that do not explicitly communicate.

      Temper that "no interactions" with the knowledge that some things are process global. Eg. the screen, keyboard etc. But iThreads design is such that it will do its best to keep your threads separate except where you explicitly choose for them to interact.

      Of course, if the threads were entirely separate, they might just as well be separate processes. Well almost. So to be really useful, it usually means that they need to communicate some way. And Thread::Queue is, to the very best of my knowledge, a safe way for threads to communicate.

      Would I use tk and threads to control a nuclear power station, airliner or baby monitor. No. But for most non-life-critical applications, I'd be perfectly happy to.

      But, guaranteed? No.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      The start of some sanity?
[reply]
        Ok. I think I've got your point.

        I still have a lesser ('cosmetic') problem though. Namely that I don't really need a queue. The main task of the worker thread is to monitor the internal state of the engine which is in fact a hash.

        The main window's handler reads this hash at regular intervals and represents it on the screen. The only commands I issue is practically 'start' and 'stop' which don't need to be queued.

        So I'm wondering in WHAT WAY is a queue safer than a shared variable?

        like: 
        use threads;
use threads::shared;

my(%state):shared;

        [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom