On 7/23/21 7:06 PM, Jerry D. Hedden wrote:
> I am the current maintainer of several core Perl 5 modules as well as some
> I have developed myself. However, I am no longer able to devote effort
> into maintaining these. As such, I would like to transfer
> ownership/responsibility to whoever would like to volunteer.
>
> The core modules are:
>
> threads
> threads-shared
> Thread-Queue
> Thread-Semaphone
>
> Their github repositories are:
>
> Dual-Life/threads-shared
> Dual-Life/Thread-Queue
> Dual-Life/threads
> Dual-Life/Thread-Semaphore
>
> Additional modules I maintain include:
>
> Thread-Cancel
> Thread-Suspend
> Bundle-Thread
> Object-InsideOut
> Math-Random-MT-Auto
>
> and their corresponding github repos:
>
> jdhedden/Thread-Cancel
> jdhedden/Thread-Suspend
> jdhedden/Bundle-Thread
> jdhedden/Object-InsideOut
> jdhedden/Math-Random-MT-Auto
>
> It's been a grand journey.
> Jerry D. Hedden
Thank you for maintaining the threads module and related. I have
enjoyed using them for many years. :-)
As I recall, concurrent programming [1] via the threading model [2]
became popular in the 1990's. Since then, I would say that support for
concurrent computing has become an necessary feature of general purpose
programming languages. For scripting languages, concurrency support has
become a question of degree -- job control, asynchronous I/O, fork/
exec, pipes, shared memory, IPC, TCP/IP networking, threading, etc..
Perl 5.005 (July, 1998) implemented the Thread module (5005threads
model) [3, 4]. Perl 5.6 (March, 2000) implemented a new model,
ithreads; but it was only available internally. Perl 5.8 (July, 2002)
deprecated the Thread module and implemented the threads module. Perl
5.20 (May, 2014) added the following warning [5]:
WARNING
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 makes 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.
I believe this "officially discouraged" position has resulted in a
self-fulfilling prophecy:
1. People will ask, "why have a language feature and then discourage
people from using it?". The warning reflects badly upon Perl.
2. Perl core, CPAN, and end-user developers will have little incentive
to make their code compatible, or maintain compatibility, with the
threads module. For example, I have discovered that threads is not
fully compatible with Data::Dumper and Capture::Tiny.
3. Perl developers who want concurrency will have one less choice.
This is the opposite of TIMTOWTDI.
4. AIUI the iThreads mailing list was de-activated due to lack of use.
This removes an opportunity for people to learn, to collaborate,
and/or to improve threads and related.
I see the following choices for the Perl threads module and all that
depends upon it:
1. Find a new maintainer, but otherwise do nothing. If/ when core,
CPAN, and/or end-user code breaks, fix threads support, remove threads
support, and/or rework affected code to use supported concurrency features.
2. Deprecate the threads module and related, and remove from core.
Begin the process of removing threads support and/or reworking dependent
CPAN and end-user code.
3. Fully support threads throughout core. Begin the process of fully
supporting (or removing) threads throughout CPAN and end-user code.
Whatever is done, I have been wanting a Perl concurrency mailing list
for many years.
David
References:
[1]
https://en.wikipedia.org/wiki/Concurrent_computing [2]
https://en.wikipedia.org/wiki/Thread_(computing)
[3]
https://perldoc.perl.org/Thread [4]
https://en.wikipedia.org/wiki/Perl_5_version_history [5]
https://perldoc.perl.org/5.20.0/threads