Howdy, If fulltest passes (on which platforms?) and Rakudo spectest is happy, I am of the opinion that we should merge it into master soon, so that Rakudo can have a shiny new feature to try out in Parrot 3.9.0.
Please send a pull request for your green_threads branch so we can do a code review. Thanks! Duke On Tue, Oct 11, 2011 at 11:29 AM, Stefan Seifert <[email protected]> wrote: > Dear parrot developers, > > during the past two months I've been working on bringing the gsoc_threads > branch up to date and into a usable shape. Now I got to the point were serious > talk about merging and future development is due. fulltest passes, as does > Rakudo's spectests. On [email protected]:niner/parrot.git I have a green_threads > branch containing my work. > > So what are "green threads"? Green threads or tasks are lightweight threads. > They exist only within the interpreter and do not use operating system > facilities like threads or processes. Instead, the interpreter itself contains > a scheduler which manages running tasks and switches between them. > > Where are we now? Parrot_pf_execute_bytecode_program got changed to instead of > calling the main sub directly, starting up the scheduler and running the main > sub as the first task. The scheduler preemptively switches tasks every 20ms. > Tasks can be started directly or as result of an expired alarm or a fireing > timer. Attached is a little test program demonstrating task switching. > > There are some restrictions to the current implementation: > * Blocking I/O and native calls block the whole interpreter, so no task > switches occur > * Preemptive task switching only works if the current task is in the top most > runloop. Otherwise the task switch is skipped and hopefully the task > returned to runloop 1 for the next task switch > * Voluntary task switching (calling sleep or pass) suffers the same > restriction. Even worse, trying it anyway will currently end up in a corrupt > stack. A workaround will be to block the whole interpreter for sleep and > probably ignore a pass. > > In short: runloops are a real hassle. But tasks can still be useful. One could > use them for handling signals for example. > > Possible ways forward from here: > An immediate improvement will be to stop preemption if only one task is > active. Or the other way around: start the scheduler's timer only when a > second task gets added to the list. This way, tasks will have zero overhead in > the common case. > > The restriction of blocking I/O could be circumvented by using asynchronous > I/O instead and and suspending the task in the meanwhile. This would be a nice > performance improvement for I/O bound programs. > > Obviously real threads could fix this as well. They seem inevitable in the > long > run anyway. But of course, those are a huge amount of work. > > Any change that removes nested runloops will be very much welcomed :) > > In any case, I think it's time to start some serious communications with > Rakudo folks about these features and where to go from now. Most of all we > need feedback. > > Stefan > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev > > -- Jonathan "Duke" Leto <[email protected]> Leto Labs LLC 209.691.DUKE // http://labs.leto.net NOTE: Personal email is only checked twice a day at 10am/2pm PST, please call/text for time-sensitive matters. _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
