Mailing List Archive

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

* David Christensen <dpchrist@holgerdanske.com> [2021-07-24 16:08:58 -0700]:

> 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
>

It's got a Bus factor of 5 and a River position of 3 - seems like this will
be a strong test of how it's handled when a module author of such an important
core module retires or gets hit by a bus or drowns in the river. Thankfully,
where it sounds like the first :-).

>
> Thank you for maintaining the threads module and related. I have enjoyed
> using them for many years. :-)

I don't use the module, but I admire and appreciate the effort and dedication
nonetheless.

>
>
<snip>
>
> Whatever is done, I have been wanting a Perl concurrency mailing list for
> many years.
>
>

Regarding the discussion of "threads" - I'd love to have one. It's a hot button
issue because many people have different definitions of what "threads" means
or should mean.

I'll just say this, perl 5.0 came out before the linux kernel had SMP support;
if the order had been reversed threads might not be such a big deal around
here because it likely would have been considered when designing the perl5 core.

If a different email "thread" was started on threads (and all the different
things that means), I'd be happy to participate. a #currency channel on irc.perl
might also be a cool idea. I tried to get an openmp@ list started recently,
and was told that no more lists are being created - so the onus may be on you
to create one. Let me know if you do, I'll join.

Cheers,
Brett

> David
>
>
>
> References:
>
<snip>

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native

On Sun, Jul 25, 2021 at 1:09 AM David Christensen <dpchrist@holgerdanske.com>
wrote:

> For example, I have discovered that threads is not
> fully compatible with Data::Dumper and Capture::Tiny.
>

The former sounds like a bug. The latter deals with a process-global
resource (standard IO), so will inherently have some funkiness.


> 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.
>

IMO what we need is to research other threading models on top of the
primitives that we have (and if needed extend those primitives).
threads::lite was my first attempt at that, though I've started a successor.


> Whatever is done, I have been wanting a Perl concurrency mailing list
> for many years.
>

We don't really need more talking, we need more doing.

Leon

On Sun, Jul 25, 2021 at 7:48 AM Oodler 577 via perl5-porters
<perl5-porters@perl.org> wrote:
> It's got a Bus factor of 5 and a River position of 3 - seems like this will
> be a strong test of how it's handled when a module author of such an important
> core module retires or gets hit by a bus or drowns in the river. Thankfully,
> where it sounds like the first :-).

It's worth noting that on metacpan, the bus factor for all core
modules is hard coded to be 5.

* Graham Knop <haarg@haarg.org> [2021-07-25 13:57:16 +0200]:

> On Sun, Jul 25, 2021 at 7:48 AM Oodler 577 via perl5-porters
> <perl5-porters@perl.org> wrote:
> > It's got a Bus factor of 5 and a River position of 3 - seems like this will
> > be a strong test of how it's handled when a module author of such an important
> > core module retires or gets hit by a bus or drowns in the river. Thankfully,
> > where it sounds like the first :-).
>
> It's worth noting that on metacpan, the bus factor for all core
> modules is hard coded to be 5.

I didn't realize that, well noted.

Cheers,
Brett

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native