Deprecate Threads

Andrew Whitworth wknight8111 at gmail.com
Fri Dec 31 15:48:47 UTC 2010


I would like to deprecate and remove Parrot's threading system. This
system does not really work for anything beyond the most trivial
tasks. Some issues:

1) Threading does not work with HLLs, (TT #757)
2) t/pmc/thread.t is very finicky and seems to provide spurious
failures every so often due to timing problems, in addition to other
issues (see TT #1905, #1340, #1248, #1120)
3) Threading, and the need to juggle multiple interpreters is causing
some weird external problems that are affecting other systems (TT
#1917 and #1880)
4) The current threading system really does not work for asynchronous
callbacks from many external libraries (TT #1192)
5) We don't have any mechanism in place to share data between threads.
We do not have STM, we do not really have locks or mutexes which are
usable, etc.
6) Creating multiple interpreters creates memory leaks and other
problems at Parrot_destroy time (TT #1765)

I suggest that we need to rip out the current threading
implementation, fix up any bugs that we can get to without it, and
start putting our heads together for a serious redesign of the system
that actually meets the needs of our users. I suspect we could have an
implementation of Green Threads put in place relatively soon (before
3.3) if we decide we want that kind of functionality either as a
stop-gap measure or as an integral part of a future threading system.

Ideally I would like to be able to put in a deprecation notice for
this system and it's related machinery (ParrotThread PMC, etc) before
the 3.0 release. However, I do not want to rush this decision, and I
would like to get feedback from Parrot's users (especially Rakudo)
before deciding to pull anything out.

Thanks,

--Andrew Whitworth


More information about the parrot-dev mailing list