cadey
/
nim-wiki
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Expanded coroutine section.

This commit is contained in:
vocalbit 2014-02-12 22:32:26 -08:00
parent 0db68fa703
commit eebf86baea
1 changed files with 7 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
GSoC-2014-Ideas.md
View File

@ -1,5 +1,5 @@
# Introduction
Below is a list of project ideas for [GSoC](https://www.google-melange.com/gsoc/homepage/google/gsoc2014) 2014. All these projects require familiarity with the Nimrod programming, or at minimum, experience with similar programming languages such as C, C#, Java, Python, etc.
Below is a list of project ideas for [GSoC](https://www.google-melange.com/gsoc/homepage/google/gsoc2014) 2014. All these projects require familiarity with Nimrod programming, or at minimum, experience with similar programming languages such as C, C#, Java, Python, etc.
We encourage you to join the #nimrod IRC channel on Freenode to discuss these projects with the community and our mentors. You may also join our [Forum](http://forum.nimrod-lang.org) to ask questions there.
@ -14,8 +14,10 @@ The following list of projects are just some ideas that the community and the de
**Description:**
Many programming languages, in particular Lua, offer coroutines as a way to provide light-weight collaborative tasking. Nimrod supports "closure iterators" which are comparable to Python's generators to accomplish the same. However closure iterators are much more limited as they cannot capture the call stack completely. The best example to see the limitations of Nimrod's current way is that iterators cannot be recursive.
Implement proper coroutines that provide light-weight collaborative multi-tasking. The coroutines must be cooperative - this means a coroutine is suspended only when it explicitly calls 'yield'. The coroutines must never be migrated across threads. This means that of all coroutines started from a thread, exactly one is running at any point in time. Other semantic details are to be nailed down as part of the project.
Nimrod already supports "closure iterators" which are comparable to Python's generators. However closure iterators are much less powerful than proper coroutines because they don't allow capturing the full call stack. This means, for instance, that closure iterators cannot be recursive.
Here is a sketch of a possible implementation, but there are lots of other possibilities to implement full coroutines for Nimrod:
* Implement the necessary stack switching via inline assembler.
@ -26,6 +28,8 @@ Here is a sketch of a possible implementation, but there are lots of other possi
* Deleting a coroutine needs to unregister the stack to the GC.
* Builtin 'yld' must save the current stack pointer so that the GC knows which part of the stack is really in use.
**Expected Result:** A working coroutine implementation in Nimrod that plays well with the GC.
**Difficulty:** Hard
**Mentor:** Araq ([@Araq](http://github.com/Araq))