I am very excited about merging this soon, but I want to make sure we don't rush it too quickly. What Stefan says about stack corruption if you try to manually switch tasks in the wrong place is troubling. It's obviously something we want to correct ASAP, and that likely will require an interface change (return a status bit so we know if it worked and bail out early otherwise, etc)
We would also like to implement his idea about turning off the preemptive scheduler if the task queue contains exactly one element. Without that fix, all existing code will run slower because of increased scheduler involvement. I think that it's unacceptable to merge something that will slow down existing code but which doesn't have to with a small amount of more work. So I'm very excited about this and I'm happy to see this branch progressing so quickly. With a bit more work I think we can get it to a place where it is all benefit and no drawbacks. Let's start looking to merge shortly after the release next week, and see what we can do between now and then. Until then, we need lots of review. --Andrew Whitworth On Tue, Oct 11, 2011 at 2:50 PM, Jonathan "Duke" Leto <[email protected]> wrote: > 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 > _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
