On Sat, Mar 1, 2014 at 9:46 PM, Christian Walde <walde.christian@gmail.com>wrote: > Earlier in the week there was discussion in #p5p about amending thread > documentation to discourage people from using them unless they really had > to. This is said patch, which adds a concise explanation of what's wrong > with threads, as well as a suggestion for alternative solution, to the > documentation of threads.pm and the threads tutorial. > > Feel free to bikeshed or merge. :) I'm not quite sure what you mean with "threads can crash easily if shared data isn't meticulously flagged". On a C level, threads::shared shouldn't segfault (and in fact, it does use a global lock[1]). If it does segfault, that is a bug that needs to be addressed. That doesn't mean you can't have race conditions (which which you might have meant), but those shouldn't result in hard crashes). The other points sound correct to me. Also, asynchronous libraries are only a useful replacement when using threads to multiplex IO, when you actually want to do multiprocessing the only alternative is forking (which obviously isn't helpful on Windows…) Leon P.S. I should really find some time for threads::lite 1: https://metacpan.org/source/JDHEDDEN/threads-shared-1.46/shared.xs#L180Thread Previous | Thread Next