in reply to Tk and Threads (again)

Just as a follow-on to zentara's excellent suggestion, I would mention that $mw->repeat(10, ...) shouldn't, I feel, be considered a bad idea. I mean, yes it's "wasteful" in the sense that there is an overhead imposed for the large majority of the time when it doesn't find anything in the queue, but at the same time, threads impose a rather substantial overhead penalty as well because they force Perl to implement preemptive multitasking within a single process, which is no mean feat.

I don't have hard numbers, but I can support this anecdotally by observing that I tried implementing something sort of like this where I needed an LWP GET request to update a Tk progress bar. I got a much smoother result by having the :content_cb subroutine from my LWP::UserAgent call $mw->update directly than by having LWP and the Tk MainLoop running in separate threads.

Replies are listed 'Best First'.
Re^2: Tk and Threads (again)
by BrowserUk (Patriarch) on Jan 22, 2006 at 22:45 UTC
    but at the same time, threads impose a rather substantial overhead penalty as well because they force Perl to implement preemptive multitasking within a single process, which is no mean feat.

    Not so. All the preemption and multitasking is done by entirely by the operating system, regardless of which OS it is running on. Perl uses either POSIX threads or Win32 native threads.

    Unlike Java and several other langauges which do implement their own mini-schedulers within each process, Perl leaves all the scheduling to the OS.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
      Huh. Didn't realize that. I guess after all of the (mostly negative) material I've read here about Perl threads I had assumed that they were totally in-process. Then it's possible I was doing something wrong to produce the clunky thread behavior I was seeing (with the timeslices not being distributed very well), or else Windows threads just do that. BTW, Java can be built with what they call "green" threads which are totally in-process but these days the default build uses native threads including NPTL on Linux.
[reply]
        Then it's possible I was doing something wrong to produce the clunky thread behavior I was seeing (with the timeslices not being distributed very well),

        I don't suppose you retained the code?

        Unfortunately about 95% of the bad press that Perl's threads get is due to people writing poor code and then blaming threads. Or worse, people who have never attempted to write a threaded Perl program, reporting and re-reporting the same three bad experiences of those brave souls that did try them--over and over and over.

        or else Windows threads just do that.

        No, There is nothing wrong with windows scheduling. And that is even more pervasive.

        If those that have switched to Linux had put as much effort into understanding their win32 systems as they are forced to learn about their *nix systems before they can do the simplest task, they may well have found that they didn't need to switch in the first place.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Seekers of Perl Wisdom