3 ms·
Let's not pretend perl threads solve concurrency issues in dynamic languages. The third item in the threads perldoc, after the table of contents and the versio
by bbatha 11y ago
Let's not pretend perl threads solve concurrency issues in dynamic languages.
The third item in the threads perldoc, after the table of contents and the version, is a big, fat warning about how you shouldn't use them [1]:
> The "interpreter-based threads" provided by Perl are not the fast, lightweight system for multitasking that one might expect or hope for. Threads are implemented in a way that make them easy to misuse. Few people know how to use them correctly or will be able to provide help.
>The use of interpreter-based threads in perl is officially discouraged.
> Perl 5 has an interpreter instance per thread, so it doesn't have a global interpreter lock. It will have other problems with threads though - you can easily run into deadlocks for example.
Which makes threads more expensive than processes on *nix because you don't get the advantages of copy-on-write processes. Also most of the librarys that use perlxs modules aren't thread-safe.
[1] http://perldoc.perl.org/threads.html http://perldoc.perl.org/threads.html
- MichaelMoser123 11y ago> Let's not pretend perl threads solve concurrency issues in dynamic languages i didn't 'pretend' that - that's a misstatement; still a big fat lock in the interpreter isn't a concurrency solution at all, instead of running concurrently your threads will be mainly blocked on the lock. Interpreter threads is an approach that does without a global lock, but as i said it is still a pain to debug the result - as you are effectively debugging both your program and the runtime. > Which makes threads more expensive than processes on *nix because you don't get the advantages of copy-on-write processes. threads are not copy on write processes; that is not unique to perl threads. The advantage of threads is that it makes easier to share data - with processes you will need to do a shared memory segment for that. Also it is less costly to create a thread rather than a process.
- bbatha 11y ago> The advantage of threads is that it makes easier to share data Sharing of data is of marginal benefit when you have to pay the cost of duplicating all of your data to begin with. Perl also has modules that make forks just as easy to use as threads.[1] This is doubly so when most libraries have little to no regard for thread safety because perl's threading support it so bad. > Also it is less costly to create a thread rather than a process. Not unix because of copy on write processes [2][3]. Perl threads copy not just the interpreter but all local variables. [4] The only place threads are useful is on windows where the cost of a fork is higher than a thread. [1] https://news.ycombinator.com/reply?id=10708168&goto=item%3Fid%3D10706695 https://news.ycombinator.com/reply?id=10708168&goto=item%3Fi... [2] http://stackoverflow.com/a/16658623/2863146 http://stackoverflow.com/a/16658623/2863146 [3] http://www.perlmonks.org/?node_id=306089 http://www.perlmonks.org/?node_id=306089 [4] http://perldoc.perl.org/perlthrtut.html#Performance-considerations http://perldoc.perl.org/perlthrtut.html#Performance-consider...
- raiph 11y ago> most libraries have little to no regard for thread safety because perl's threading support it so bad. Fwiw Perl 6's concurrency and parallelism is very much one of its strengths, not one of its weaknesses. (It's pretty obvious to me that you are writing about Perl 5, not Perl 6, but it might not be obvious to others. Indeed some folk will even claim Perl 6 isn't a Perl, but Perl's original creator Larry Wall thinks Perl 6 is a Perl, and I think he has a point.)
- pfortuny 11y agoOh, but that refers to perl 5, for which threads were always something of a bummer. As far as I can tell, concurrency and parallelism in perl6 are a quite different and really powerful tool.