|There's more than one way to do things|
(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.)
In reply to Re^3: Threads and signals in Windows (invoking the name)