green_threads
Andrew Whitworth
wknight8111 at gmail.com
Tue Oct 11 18:58:53 UTC 2011
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 <jonathan at leto.net> 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 <nine at detonation.org> 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 git at github.com: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 <jonathan at leto.net>
> 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
>
More information about the parrot-dev
mailing list