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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
