This is an exception and I was disappointed. The summary of the meditations is that, allowing FUD to spread creates monsters and we collectively are responsible. Now, I fully understand that it isn't your job to impress me but I truly was hoping for some examples of how it hurts the community, the image of perl to outsiders the fledgling programmer, etc. I personally have learned one of the dangers of spreading FUD - even when it was unintentional (I pissed someone off that I respected and relied on for help).

Before I became immersed in the perl community, I had no idea how many freaking insanely smart people were out there. In general, I find it full of autodidacts willing to spend vast amounts of time learning. We also tend to be more helpful than obstructing and more friendly than antagonistic. I am not trying to paint with blinders on that the community is some kind of utopia - just that I really like it. There are numerous long discussions that go over my head and I am amazed at the breadth and depth of the knowledge. Many even fly in the face of Godwin's law.

I know pitifully little about threads to know FUD from non-FUD. I can't defer to one or the other based on experience and knowledge because you are both titans from my perspective. I know you would rather have a concrete code example at the center of debate but might I propose another alternative?

I just checked and there are two tutorials regarding threading. I have no idea if they are any good and it doesn't really matter - I am suggesting you write a third. A really long one - basically the ADD cliff notes of what should be a book I would never buy nor read. Cover what threads are, both from an OS and a language perspective. Provide pointers to good well written references to historical information, etc. Introduce perl threads and there long purportedly sordid history. Enumerate each distinct assertion you consider FUD and then explain why it isn't really true (or when it stopped being true). Go into the true disadvantages (assuming there are any) and what things you should consider before using threads. Then, go into a very basic example of using threads commenting on why you did this but avoided that. Continue on to more complex examples. Use, or reference, real examples from the site where using a threaded solution was the right way to go.

Here is the promise I make to you if you take up my challenge: I will work through the tutorial finally learning an aspect of the language that I have blissfully remained ignorant of for 8 years (admittedly mostly due to negative impressions from others). I will either become a convert and rally behind you whenever I see FUD - pointing to the tutorial as proof or I will find you full of BS and at least I personally will have the answer to who is right. Of course, a third possibility exists - I will find problems that you haven't encountered and working through them will elucidate the matter for both of us.

This is an exception and I was disappointed. ... I truly was hoping for some examples of how it hurts the community,

I gave the most clear example relating to this particular piece of FUD that is available. It was not a personal attack, he's an unknowing victim of the FUD. There have been others in the past and there will be more.

You admit to "know[ing] pitifully little about threads". You don't have answer this in public or private--or even think it out loud. But how much of your reasons for never trying iThreads comes down to hearing/seeing other monks you respect dismiss them out of hand?

Your Mother has (kindly) stood up to be counted as one of those who has previously been put off from even trying iThreads because of the general negativity, misunderstanding and FUD that surrounds them.

I have personal knowledge of several other monks who have, in private, said the same thing. That it was only through my demonstrations of how effective and simple iThreads can be for some classes of every day problems that led them to get over their bad rep and try them.

In the same way, whenever I get a bout of depression over Perl6, moritz will pop-up with one of his demonstrations of just how concise and elegant some problems can be solved using Perl6. It keeps my interest alive, if only latently.

I did consider making reference back to my predictions that PBP would become a rod for the backs of Perlers everywhere--and attempt to show how, in the intervening 5 or so years that prediction has come true. Or another of my predictions, that perl-critic would start to be used to define lore, rather than support it; and how that has manifest itself here on occasion. Or how my "The future is threaded" prediction has come true far faster and more ubiquitously than even I ever imagined when I wrote it. Well everywhere except for Perl anyway. Or how accurate my prediction about a certain meditation, that I refuse to reference, would set back the development and use of iThreads. But all of these would only serve to re-open old sores. Something I have no interest in doing. Even mentioning any of these is a red rag, but at least without links, it will require actual effort to re-start those debates.

I just checked and there are two tutorials regarding threading. I am suggesting you write a third. A really long one.

1. Cover what threads are, both from an OS and a language perspective.
2. Provide pointers to good well written references to historical information, etc.
3. Introduce perl threads and there long purportedly sordid history.
4. Enumerate each distinct assertion you consider FUD and then explain why it isn't really true (or when it stopped being true).
5. Go into the true disadvantages (assuming there are any) and what things you should consider before using threads.
6. Then, go into a very basic example of using threads commenting on why you did this but avoided that.
7. Continue on to more complex examples. Use, or reference, real examples from the site where using a threaded solution was the right way to go.

I'd love to be in a position to do that--but I am not. I simply do not know enough. Whilst it may be the case that I know more about using iThreads than many, may be even most, other monks. I still don't know enough.

What I know has come not from any special insights into the internals. I know my way around the sources pretty well, but there are still points in there that I find impossible to follow. But that stems mostly from the lack of readily available help with XS programming issues. Indeed, if XS programming was less of a trail&error, hit'n'miss affair, I might well have finished a whole raft of things I've started, but abandoned, because I couldn't find solutions to mysterious XS problems.

Nor does it come from any particular "special threading skills". Though I've been using native (kernel) threads for around 23 years. My first threaded program was written in assembler and compiled under the then-called CP/DOS. It used Beep(), to signify that particular threads were running, because that was the only thread-safe IO call at that early point in the development.

It comes entirely from having made regular use of iThreads on a daily basis, continuously for the last 8 years or so. The problem is, my knowledge is still evolving every day. I discovered a new wrinkle in my knowledge just the other day which perhaps seems fairly insignificant, but screws up one of my long-established 'patterns of thread usage'. At least on non-windows platforms. I've always been painfully aware that my "expertise" is limited to that platform. I thought for a while that using ubuntu within a VirtualBox environment would make testing stuff on *nix bearable, but that turned out to be a false dawn. Every time I used a VBox window, it usurps my internet connection and I have to close it down and re-start the PPP link to restore it.

And many of the recurrent techniques I use aren't even my discoveries. I've adopted (and often adapted) them from other peoples code. For example, in my early thread code you'll see me pushing 'well-known values' onto queues, and detecting those values within thread-queue read loops to cause them to terminate. I think it may have been zentara whom I first saw use the now, ubiquitous while( $Q->dequeue ){...} ... $Q->enqueue( (undef) x $THREADS ).

Again, the other day I adapted a snippet from a piece of code of which I was mostly rather critical, because after all these years it showed me how to cleanly do something that I've previously had to work much harder to achieve. That something is a clean way to use detached threads. The main problem with detached threads is that they do not show up in any of the threads->list( ... ); variants. So, once you have detached them, you have no ready mechanism for your main thread to know when they have finished running.

Previously, I have used one of two mechanisms to deal with this. Either I do not detach them so that I can use $_->join for @threads to detect when they've finished. Even though I am not interested in their return values--which is what join is for.

Or, I use a shared variable in my "count'em out and count'em back" pattern:

my $running :shared = 0; 
sub thread{ 
    {lock $running; ++$running; } 
    .... 
    lock $running; --$running;
}

...
sleep 1 while $running;
[download]

But the code I referenced above did something I'd never seen before, and never thought to try:  threads->detach;. Essentially, it only detaches the thread just before it finishes. That simple expedient means that the threads are reported by threads->list( threads::running ); right up to the point where they finish. Which in turn removes the need to either join those threads; or use the shared variable and associated locking. My main threads can now use a simple: sleep 1 while threads->list( threads::running } to determine when it is safe to let the program end.

The upshot of all that is, I'm still learning. But not--for the most part--from others with greater expertise, but simply from seeing things I perhaps wouldn't have done in their original contexts, but that make sense in some other context.

And therein lies the rub. With so few people posting their experiments, experience and knowledge of using iThreads, both the knowledge base of what they are capable of, and fixes for the problems that arise, moves forward very slowly. And in good part that comes down to people having been put off in the past by their bad rep.

In part, that bad rep stems from early problems associated with retro-fitting them into a completely non-thread aware mass of complex software once accurately described as the software equivalent of 'Pick up Stix'. But in (I think) greater part, stems from FUD that originates from, and is perpetuated by, those who view threads as un-Unixy. (note:threads; not just iThreads.) The fact that iThreads evolved from an MS-backed (if not driven) initiative to provide a fork emulation for Perl on Windows doesn't help in that regard.

But the not-so-subtle distinction between iThreads enabling that fork emulation, and their being that emulation--even on platforms that neither need nor use that emulation--is apparently too subtle for some people to grasp.

Of course, for others, the distinction is all too obvious--and too threatening to their own Holy COWs--for them to allow the distinction to be well-known and discussed. Despite that it is manifest.

So, I'm afraid it will not be possible for me to pick up your challenge--despite both the will and the desire--because I simply do not yet have the knowledge to rise to it. And there are no works of reference I can consult in order to bolster my knowledge; I am, in large part, the reference. But there are still too many blank pages to risk attempting to commit anything other than working code to the vagaries of the nit-pickers, sound-bite evangelists and thread-is-spelt-fork, luddites.

Sorry to disappoint again, but what you ask is not doable.

---

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

BrowserUk,
You don't have answer this in public or private--or even think it out loud. But how much of your reasons for never trying iThreads comes down to hearing/seeing other monks you respect dismiss them out of hand?

I actually answered in my post. To quote myself: "I will work through the tutorial finally learning an aspect of the language that I have blissfully remained ignorant of for 8 years (admittedly mostly due to negative impressions from others)."

I've always been painfully aware that my "expertise" is limited to that platform....Every time I used a VBox window, it usurps my internet connection and I have to close it down and re-start the PPP link to restore it.

Personally, I would be happy with whatever expertise you would be able to provide even with the limited scope of targeting windows. Regarding the loss of internet, a similar thing happens when using VPN software. I have found in most cases I simply need to modify the routing table. I have no idea if that is even applicable here but that's how I have surfed the net while also having an established VPN.

So, I'm afraid it will not be possible for me to pick up your challenge

Perfection is the enemy of good enough (Voltaire). Your knowledge is far more than my own. You could teach me - I have no doubt in that. Even if you fell short, many would still benefit.

Sorry to disappoint again, but what you ask is not doable.

Well, I hope you change your perspective but if you don't I understand. Thanks for what you do contribute even though it does sometimes come across as snarky - I do appreciate it.

Cheers - L~R

I'd love to be in a position to do that--but I am not. I simply do not know enough.

You serve nobody with overdone modesty.

Your posting clearly show that not only you do know a lot about ithreads but also that you can communicate your knowledge well (I am refering to the technical contents of your postings).

A new ithread tutorial from you would be an extremely valuable contribution to this site.

And should that provoke Coro's supporters to counter that with tutorials of their own then all the better for the community.

Me, I just look forward to the days when your pissing-match with everybody who mentions "threads" and "forks" in the same sentence is over.

Pissing match? Copious examples on using threads are not a pissing match, I much prefer them to rumors and fairy tale rants

It's a little more complicated than that, but it is understandable that you aren't interested in the detail. But you do have the choice of simply not reading them.

However, if you find that unacceptable, perhaps you could post a list of subjects that are important to you, to which I should restrict myself?

What's more, if you can get a consensus--let's be generous and say, 1% of the active membership--on what those subjects should be, I'll be so bound.

that you aren't interested in the detail

As it happens, I am somewhat interested in the issues that are discussed. Concurrency is an important element of programming and discussions about the possibilities of various concurrency models can be enlightening. While I remain securely in the camp that favours a process-based model, it never hurts to hear a differing view, and some of the things you said e.g. about why you think ithreads is a strong concept that's just not implemented ideally, were illuminating. So thanks for that. And YMMV in these things, always. Just because I don't agree with you doesn't mean I find your POV unworthy of consideration.

I just wish these posts were not coated with such an unappetising sheen of belligerence. And, though you may be surprised to hear that, I perceive most of the antagonism originating with you (this perception, naturally, is mine alone and I make no claims that it may be shared by others). Which makes it harder and less pleasant to dig through the threads in search of actual information hidden within the barbed comments.

As for your implication that I am trying to censor or limit the things you should talk about: Please! Enough with the paranoia already!


All dogma is stupid.

A guru was asked by a grasshopper, "which is better, Perl or Python?"

The guru responded: well Perl is faster..... At which point the grasshopper said "Ok then, so I should use Perl"

The guru responded, well maybe, but 6 months from now, when you come back to look at the code, Python makes it easier to remember what the code did. :-)

Sounds like you might possibly be referring to "Python vs. Perl according to Yoda".

The threads threads have been quite valuable to me. I had long ago dismissed threads in Perl as dangerous nonsense precisely because there is a semi-pervasive attitude around and about that intimates that without always coming out with it. I will be trying to use them the next time it seems appropriate, probably with some stock quote streaming stuff I've been messing with, and I would not have considered it without your messages and copious sample code.

(Sidebar: I know the personal angles in the arguments are easy to fall into but they aren't much fun to read.)

You seem to brand honest misunderstanding as FUD sometimes. I think that's a mistake, given the original intent of the FUD concept, even when, in a literal sense, there's at least uncertainty and doubt in these cases, whether or not there's fear. (Note, this is an impression, I haven't done any sort of an exhaustive survey. I just think that your metaphorical FUD-label-gun has a hair trigger and you an itchy finger.)

That being said, when people repeat complete nonsense as fact without even testing it, there's rarely a reason to be particularly gentle. And I think most all of us have limits on our patience for certain misunderstandings, which vary from individual to individual. So, I certainly sympathize with the sentiment even when I disagree with the approach.

I'd just like to clarify that I do not consider him the purveyor of FUD--he's the victim of it.

Gentlebeings, please let us all agree among ourselves that everyone has their opinion, and that a thing which might be “right,” probably is not the only thing that could be said to be “right” in the same situation!   Didn’t I once hear someone say, TMTOWTDI?

And when we do come here to meditate, let us all bear in mind ... and when I say us all, I emphatically do include myself ... that a monastery is a quiet and respectful place.   Let us talk about Perl, mediate and ruminate about Perl, but strictly hold off-limits any personal comments or judgments about each other.   Nor should we confuse our judgment about an opnion, as a judgment about the person(s) who hold it.   (And I do not say that as a sideways-slap to any particular individual.   I’m not that clever.   We should do this of our own free choice because perlmonks.org will be a better resource thereby.   And that’s what this site is... a valuable professional resource.)

Debate, debate, debate, argue, debate, debate.   Ding!!   Okay, time’s up.   (I still think so-and-so is full of <!> but...) workday’s over now ... time for a beer.

Is it “important to counter FUD?”   Probably not, actually.   It just isn’t worth the cost.   Just watch it float away down the river and disappear.   (Make your own personal contribution to that river if it makes you feel better, but please go behind the trees.)   But... then... let it go and be gone.

Is it “important to counter FUD?” Probably not, actually. It just isn’t worth the cost. Just watch it float away down the river and disappear.

Flotsam and even jetsam, may float away on the tide, but mud sticks.

Hence, in many circles, Perl(5) is still stuck with the "readonly line-noise" tag that originated from Perl(4) days. Even in an age when many of the users of that tag have little or no understanding of what "line-noise" actually looks like.

It's pretty intolerable when it originates outside the community. Far worse when it comes from within.

So I think it is important. See the second quote in the first line of my sig.

Or as another monks tag has it: "You have enemies? Good, you stood up for something in this life." credited to Winston Churchill. Maybe there's something in the local water.

---

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

I'm a virgin, thanks :)