Pure, unadulterated garbage.

Excellent comments, BrowserUK. Very informative.

Invoking the name failed again, give it up now?

(Shrug...)   I have long ago resigned myself to the realization that there is nothing I can do or say to change this man’s opinions about me, and so I spend very little time thinking about that.   Furthermore, that’s not why I said what I did.   I meant it, nothing more or less.

And, “unadulterated garbage” or no, I meant my follow-on comment also.   Multi-threaded solutions have a long reputation for being unreliable, and it always comes down to:   a timing problem.   Something that “appeared to work okay” on the developer’s machine that fell apart when subjected to real-world conditions.   The very same edge-cases that were discussed earlier in this thread.   “Signals,” which are by definition a form of rendezvous that occurs at a particular arbitrary instant in time (and which are handled asynchronously) ... instability which occasionally but not consistently shows up even to the developer ... attempts to “fix the problem” with pauses ... and at the end of the day a design problem that simply will not go-away like that.   Signal-based designs are tightly coupled, while resilient and scalable designs are loosely coupled.   You see evidence of that in all kinds of workload-management software ... JBoss, for instance.   Stuff that has nothing to do with Perl.   Any timing-based assumption is a kiss o’s death.

If you want to see how a reliable multi-threaded system works, just go order a burger at McDonald’s and watch how their system works.   It is all implemented by human beings and connected by queues.   Machines signal humans, but humans don’t signal each other.   It works just as well, and it works the same way, whether the place is empty or full.   If something breaks down, it automatically recovers.   The computer systems that they use today are simply an implementation of the workflow management system that first attracted the attention of Ray Kroc to what the McDonald brothers were doing.   The thing to observe is ... their process, itself.

If your design is running anywhere close to being affected by the “edge cases” that differentiate Linux from Windows, then IMHO you need to change that design.   To get back well away from that edge.   To use something other than bare signals ... to build a different design that does not require these things.   A design with no need to care.

I will respond as best I can, try to be as helpful as I may be to the original poster and to the thread, and yes, I will give credit where credit properly is due.   I said what I meant, and I meant what I said.   And somehow, despite all that, accumulate 12,530 experience points and counting.   (And, yeah, I know that’s small change by comparison, but to me this is not a competition.   It’s just trying to help other Monks.)

I have long ago resigned myself to the realization that there is nothing I can do or say to change this man’s opinions about me,

I expressed no opinion about you; only what you wrote: which was:

1. Almost completely irrelevant to the subject of the thread.

   WTF have persisant threads got to do with fork and signals emulation on Windows failing to match the behaviour of real fork and signals on *nix!

   How the F*** are you going to “informed that it is now time for them to please roll over and die.”; when "it", is a separate process currently blocked in a kernel IO call? Take out an ad in the Times. Yell really loudly.

2. Even the answer you gave -- which was to a completely different question -- was wrong in at least four ways!

   How can a thread both be: a) listening to a queue; b) monitoring a shared variable and c) waiting for IO?

   This: " Control the system with messages. Indicate that it’s time to die with a shared flag, and also send a message to that effect so that any thread that’s listening on a queue will wake up, read it, put its own house in order, and die. " is just a conflagration of snippets of algorithms that you've read about -- but never tried to use -- taken out of their contexts and regurgitated en-masse as an unholy ensemble of nonsense.

I try very hard to live up to the proverb in my sig: "Examine what is said, not who speaks"; but when someone consistently, and repeatedly, and despite all attempts to point out the inaccuracies; misunderstanding; and just plain crap their responses contain; continues to respond on subjects that it is clear to anyone with even a modicum of knowledge, they have nothing useful to contribute; then yes, that does color my opinion of that person.

I will respond as best I can, try to be as helpful as I may be to the original poster and to the thread,

You are helping no one by responding with such utter garbage in threads on subjects it is patently and painfully obvious you haven't got the first clue what you are talking about.

If you want to change my opinion of you: A) stick to what you know; and realise you are fooling noone; b) try writing some code. Try putting some of your"advice" into practice; you'll soon discover why it incenses me so to see you make shit up and offering it to others in the guise of knowledge and guidance.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

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.

So now you're invoking the McDonalds?