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.