green_threads

[Jonathan "Duke" Leto]

Howdy,

Any chance that you can give an example in NQP or Winxed? They would
make very good tests as well.

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.