in reply to Re^5: Your main event may be another's side-show. (Coro)
in thread Your main event may be another's side-show.

I've not used Perl "threads" under Windows even for simple tasks because every time I've tried I've found bugs almost immediately.

Really? You've never asked for help. Which makes you a silly billy, because at a rough guess about 80% or more of the "threads bugs" posted here have been user errors. And of the rest, there is usually a relatively simple workaround.

And I've seen many projects start out just fine using threads and then have an ever-increasing set of problems with race conditions, deadlocks, and lack of concurrency.

Then post the code and let me fix it for you.

I'd be fascinated, because as I said somewhere else here yesterday. In 8+ years I've never encountered a deadlock with ithreads.

Avoiding deadlocks is simple. You just don't write code that creates the situations where they can occur.

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.
RIP an inspiration; A true Folk's Guy
  • Comment on Re^6: Your main event may be another's side-show. (Coro)

Replies are listed 'Best First'.
Re^7: Your main event may be another's side-show. (Coro)
by tye (Sage) on Oct 21, 2010 at 20:21 UTC
    You've never asked for help. Which makes you a silly billy, because [...] the rest, there is usually a relatively simple workaround.

    Yeah, running into a "panic" at step one with trivial amounts of code makes me shy away from putting my full weight on something. A work-around can be a nice thing. Needing a work-around out of the gate when the code hasn't hardly even started being written is all I need to find a different solution. And you not having noticed me asking for help doesn't actually demonstrate much about how much help I have sought or not.

    In 8+ years I've never encountered a deadlock with ithreads.

    Yeah. iThreads emulate fork(). You don't get deadlocks with just fork() either. When you tie yourself to a framework like iThreads, that is one of the benefits. But since fork() is so much more efficient in memory and CPU than that emulation of it (and is better supported and less buggy), I use the real thing not the emulation.

    - tye        

[reply]

      Okay. That's what I thought. No real desire to discuss the issues.

      Just another FUD-laden he's-pro-so-I'm-anti rant. You're not as good at them as you used to be.

      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.
[reply]

        I responded to your points. I'm guessing now you wanted me to enumerate some specific problem case I ran into with iThreads. The problems were several (and sometimes dramatic) but none recent. I don't have any handy. I already said I'd try iThreads again on Windows at some point so if you want to paint me as throwing FUD at iThreads, have as much fun as you want with that.

        You started the "I'm anti" "rant" and even promoted it into its own thread so moaning now about having to put up with opposing viewpoints is rather sad.

        Perhaps you have little experience with programming with real threads so much of my exposition is foreign to you? That part is somewhat tangential to scripting with "current" Perl.

        I was speaking in favor of using coroutines and contrasting that approach with other routes that are more commonly (IME) taken instead of late (not just when using Perl). The prior instability of iThreads surely can't have been a mystery to you but also is of little import in what I wrote. (Though, I suspect that, having had to learn the work-arounds early on, you were also less aware how long the embarrassing ease of finding major bugs persisted.)

        In one paragraph I juxtaposed talk of iThreads with talk of real threads which was unfortunate and easily confusing. iThreads are of no interest in the primary cases that lead to me considering Coro because the motivation is reducing process overhead and iThreads add more overhead than fork() would. Their prior instability matters not nor does their lack of deadlocks, only their bloatedness compared to plain old fork() (or just spawning).

        If your "No real desire to discuss the issues" is only in regard to prior bugs in iThreads, then it is unfortunate that you missed almost completely the point and have no interest in discussing any of the other "issues".

        - tye        

[reply]

In Section Meditations