Front page | perl.perl5.porters |
Postings from April 2018
On Mon, Apr 09, 2018 at 11:01:22PM +0200, Christian Walde wrote:
> > 2) If one's threaded code randomly craps out due to a 3rd party module
> > being non-thread-safe, or supposedly thread-safe but buggy, then that's an
> > issue with the third-party module. In principle any programming language
> > will struggle with threads if used with a 3rd-party library that isn't
> > thread-safe.
>
> This has dangerous assumptions in it:
>
> - Thread safety is not a binary on/off switch. Modules can appear to be
> thread-safe under some conditions and not be so under others. That's why
> i called it a heisenbug in my previous email.
>
> - Putting the blame on 3rd party modules is fine for most languages
> where it's easier to switch to other implementations or roll your own.
> However this is Perl. The language lives on CPAN, not in the
> interpreter. Asking someone who just spent hours implementing a parallel
> web downloader to gradually replace any of the bits they used will not
> be taken well.
>
> - Very few cpan maintainers know how to do thread-safety. Heck, most
> don't even practice string/binary safety for filehandles. Most of them
> are Perl developers first and you're asking them to move at least 2
> degrees of separation outside of their zone of comfort. For a lot of
> modules there's simply a good chance this is not going to happen.
But everything you've said above applies just as much to any 3rd-party
library/module in any programming language which supports concurrency.
I really fail to see how CPAN is different in this regard.
Most CPAN authors don't need to worry about thread-safety, as long as it's
a perl-level module. Perl is thread-safe at the language level, and you
don't need to do anything special to make Perl code thread-safe. Or at
least, nothing more than you would have to do to make your module safe
across forks (which is what ithreads is emulating after all). For example,
if a thread is created, the module's variables will be cloned, and a
destructor might be called for a variable in each of the threads. And of
course if the module is updating something external like a file, then it
may need to exclusively lock that file.
XS code is of course a lot harder, because now you're doing concurrency
programming in C. But even here, its easier than general C concurrency,
because of perl's ITHREADS "not shared by default" model. You mainly have
to avoid global/static mutable data, and be prepared for any of your
data stored in SVs (e.g. DB handles) being cloned when a new thread is
created.
--
All wight. I will give you one more chance. This time, I want to hear
no Wubens. No Weginalds. No Wudolf the wed-nosed weindeers.
-- Life of Brian
Thread Previous
|
Thread Next