enable multithread with Thread::Queue

  • Serg

    Serg - 2013-10-29

    hello, i've just tryed to debug this "hello world" app

    1. use strict;
    2. use threads;
    3. use Thread::Queue;
    4. print "Hello world";

    which causes the following errors

    lock can only be used on shared values at {path to workspace}/.metadata/.plugins/org.epic.debug/perl5db.pl line 4100.

    As mentioned in http://search.cpan.org/dist/perl/lib/perl5db.pl#THREADS_SUPPORT,

    the environment variable PERL5DB_THREADED is set, to enable proper threaded debugger control. -dt can also be used to set this.

    I tryed 'perl -dt xxx.pl' and it was working.

    so, i'm little confused, how to properly achieve the same in EPIC?

    when i tryed to setup -dt as perl argument in my 'Perl local' configuration, the debugger couldn't stand on breakpoint at line #4. However, when you comment line #3, the debugger works fine without any additional Perl arguments (and i can even debug simple multithread applications).

    OS: Win7 64x, Eclipse Kepler Version: 4.3.1, EPIC 0.6.53, Strawberry Perl v5.18.1 MSWin32-x64-multi-thread

    • Jan Ploski

      Jan Ploski - 2013-10-29

      There's no support for threads in EPIC whatsoever. Anyway, why use threads in Perl at all? Multiple processes or non-blocking event loops seem to be the more standard approach.

      • camelcoder

        camelcoder - 2014-04-01

        Agree that multiple processes and clever event loops are preferable, but there are a few use cases that make threading appealing:

        1) The promise that thread functionality from a method standpoint (as implemented by Perl) will be standard and supported across platforms
        2) data sharing, locking, queuing, etc. is pre-existing functionality
        3) We inherited or are working with somebody else's program. Rewriting it to be multiprocess is not reasonable.

        This means that as a programmer I can expect any Perl that is built with thread support to support all such methods, in effect insulating me from the individual horrors of different platforms thread support. Going further, insulating me from supporting multiple platforms/multiprocess support.

        So it's not that I am extolling the virtues of Perl threads, but I am appreciative of being insulated from having our programs behave unexpectedly on platforms we might not use or have access to. Whether or not you support it as the EPIC developer is your prerogative, but I hope this adds some justification for why your users might want it.

        • Jan Ploski

          Jan Ploski - 2014-04-01

          Other languages insulate you much better from the horrors of multiplatform thread support than Perl. The threads implementation of Perl is poor (not just on the front of efficiency, but also concerning compatibility with existing modules, which arguably is the main reason to use Perl in the first place).

          That is probably why few people ever use this feature (prove me wrong), which in turn is why development tools don't support it.

          For example, consider that you're the first person who asked about it during multiple years of this IDE's existence. However, EPIC being what it is, you could always jump in and contribute patches for such features that you consider worthwhile (as long as they don't impair existing functionality). The development efforts would then also have to be counted as the true cost of deciding to use Perl threads.

          • camelcoder

            camelcoder - 2014-06-03

            How do I prove that people want to use threads?
            Well, how about cpan, which has at least 98 modules supporting it?
            How about multiple iterations of Perl which improved upon threading?

            Your question is ambiguous or maybe it was rhetorical?

            Whether or not existing modules are thread safe is neither here nor there to what we're talking about, though. I happen to have the same problem as the original poster to this question. Not to speak for the other person, but I would guess that we are both here posting these messages in this forum to you (and whomever might be reading) because we want you to know that we care about the feature, and it's something we were trying to do, and we could not.

            In my case, I inherited someone else's program that is complex, and it uses threads. You can tell me that it's a silly idea all day long, but it doesn't change the fact that I inherited someone else's decision to use threads, and I tried to use EPIC to wrangle the problem. And it would not run.

            And no, I'm not able to contribute patches to your product. The company I work for would have to approve such things.

            It would be great if EPIC supported threads. That is all I'm saying. In internet discussions of programming languages and decision-making, there's often many reasons for why people are going about their business the way they are beyond the control of the individual that is in the situation.

            I prefer the Perl motto in these discussions, There Is More Than One Way to Do It.

            By the way, we have spoken before under a different name, and it was friendly. Your product has been very helpful to my life and livelihood, my productivity, and you have my thanks for your contribution. It's been meaningful. Please don't take a feature request as something other than what it is- a feature request. You have my gratitude and respect for everything you have done so far.

            This is only feature request.

            • Jan Ploski

              Jan Ploski - 2014-06-03

              I understand your woes, but that understanding alone won't help you :/

              Maybe someone else, with an own itch to scratch and more eagerness, will come around and look into implementing that feature for you. "There Is More Than One Way to Do It" is a good motto and certainly better than "There Is One Way to Do It". Still, it has the drawback that not all ways are equally feasible (from the standpoint of effort required) nor are they subjectively equally preferred by different people.

              To put it another way, if you're afflicted by a rare disease, your only hope is that someone will develop an "orphan drug" for you. Even if you're lucky in that matter, the cure is likely going to be much more expensive than if you had a more "popular" disease. This causal reasoning may also be reversed into diagnostic: if your drug happens to be unusually expensive, then as a plausible default you might assume that your disease belongs to the "rare" category. There are of course other explanations you could make (such as "the world is an evil place", "people are cruel"), but not all are equally useful/actionable.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks