Now that I'm starting to write a real async scheduler on top of Wren's
basic fiber API, I have a better feel for what it needs. It turns out
run() is not it.
- Remove run() methods.
- Add transfer() which leaves the caller of the invoked fiber alone.
- Add suspend() to return control to the host application.
- Add Timer.schedule() to start a new independently scheduled fiber.
- Change Timer.sleep() so that it only transfers control to explicitly
scheduled fibers, not any one.
- Create separate libs for each architecture. OS X doesn't need this
(we just build a universal binary), but it will help Linux.
- Move the libuv build stuff into wren.mk where the actual dependency
on the lib is.
- Download libuv to deps/ instead of build/. That way "make clean"
doesn't blow it away.
- Don't redownload libuv unless needed.
This adds a "timer" module to the CLI that provides a Timer class with
a static sleep() method. Not the most exciting functionality in the
world, but it requires the full hunk of libuv integration:
- The CLI sets up libuv and runs the event loop.
- Added a new directory src/module for CLI modules.
- Updated all the make scripts to handle it.
- Reorganized some other CLI code.
- Add a script that downloads and compiles libuv.
- Hook that up to the Makefile so it pulls down libuv on build.
- Add a separate "vm" target that just builds the VM library and skips
libuv.
- Link to libuv when compiling the CLI.
- Update the XCode project to link to libuv too.
Linux and Windows support isn't done yet, but it should be pretty
straightforward to add to the Python script.
* Eliminate "new" reserved word.
* Allow "this" before a method definition to define a constructor.
* Only create a default constructor for classes that don't define one.
If a test expected an error and found at least one, it would not fail
on any other expected errors that didn't occur.
Also, some tests were expecting a compile time error message even though
the test script doesn't validate those (yet).
The test function was getting monolithic, so I went ahead and split it
into a separate little class.
Previously, fibers had a hard-coded limit to how big their stack size
is. This limit exists in two forms: the number of distinct call frames
(basically the maximum call depth), and the number of unique stack
slots.
This fixes the first half of this by dynamically allocating the call
frame array and growing it as needed. This makes new fibers smallers
since they can start with a very small array. Checking and growing as
needed doesn't noticeably regress the perf on the other benchmarks, and
it makes a new fiber benchmark about 45% faster.
The stack array is still hardcoded, but that will be in another commit.
Bob Nystrom
Rohan Singh
Kyle Marek-Spartz
Luchs