GSoC: Adding support for asyncio in batavia (draft)

[AasthaGupta]

Updated on 27th March 2018

Introduction

Current implementation of Batavia includes many features of python but lacks python (3.5+) asyncIO feature. Implementing asynchronous concurrent event loop will not only help in supporting this feature but also help in building infrastructure for asynchronous message passing that can be used by websockets to provide real time message passing between server and client.

Summarised Deliverables

My goal will be implementing the infrastructure for python asyncio functionality and connecting same with websockets to provide feature of real time message passing between server and client. Building infrastructure can be further broken down into sub-tasks as follows

• Basic asyncIO functionality
• Tests and documentation

Proposed Timeline

>>> Phase 1 : Implementing Opcodes

Every python code is parsed into python intermediate language which is then executed by the interpreter. Batavia executes python bytecode directly by emulating each opcode in JavaScript. To support asyncio we need to implement few opcodes which are right now missing in batavia system. This list includes

• GET_AWAITABLE (0x49)
• SETUP_ASYNC_WITH (0x9A)
• BEFORE_ASYNC_WITH (0x34)

List of supported Opcodes by batavia After opcode implementation,

• Batavia VM will be able to identify tokens such as async and await
• Batavia VM will be able to support coroutine objects and functions Before starting with the implementation of opcodes, I first need to:
• Implement AsyncIO module structure in module/asyncio.js. Layout class structure and all the basic functional methods that are required in the implementation of asyncio library. It will create barebone structure that will be used in later stages of development. This will help in linearly implement the functionality dependent on other functionalities.

Schedule

• Week 1: Deep dive into CPython asyncio implementation to prepare a list of all the necessary opcodes.
• Week 2: Implementing AsyncIO module structure in module/asyncio.js
• Week 3: Handle the implementation of prepared list of opcodes in Batavia.
• Week 4: Build support for Coroutine object and functions.

>>> Phase 2 : Implementing asyncIO module

At the end of phase 1, I will have coroutine support and all the barebone functionality of the asyncio library including the function definitions with appropriate return types and arguments. So, in this phase my focus will be on implementing the inside functionality of these functions. Asyncio python library helps in creating cooperative multitasking environment for event based blocking threads. This is implemented through a event loop that keeps a track of all asynchronous coroutine objects and invoke them one-by-one. Even though Javascript and Node supports asynchronous cooperative multitasking but Javascript runs in a single thread and event loops are internally scheduled within that thread, This way we will have very limited control over the event loop. So it is better if we create our own event loop and control scheduling of async tasks/coroutine. Implementation of this library can be broken down in following sub-tasks:

• Implement Event loop Event loop handles all asynchronous callbacks in asyncio. So I have to implement a set basic functionality which will include loop object creation, threading, loop future callback and loop handing. This will add support for following basic functionalities in asyncio.js module
• A function to get the default event loop of the current thread: Get Event Loop: asyncio.get_event_loop()
  • A function to create event loop: asyncio.new_event_loop()
  • Function to set event loop for the current thread: asyncio.set_event_loop()
  • Run loop continuously: loop.run_forever()
  • Return the state of the loop: loop.is_running()
  • Stop loop: loop.stop()
• Implement other supporting Functions
  • Sleep: asyncio.sleep() Asyncio.sleep make a event loop callback, this is important to make cooperative multitasking possible within event loop.
  • Create Task: loop.create_task() Asynciouse create_task to define a new coroutine object and add/schedule it to the event loop.
  • Create Future: loop.create_future()
  • can be expanded later on based on scope of module support

Schedule

• Week 5 & 6: Implement event loop creation functionality in javascript. The JavaScript threading support can be used to implement this.
• Week 7: Implementing event loop holder that will help in maintaining event loops in the JavaScript.
• Week 8: After implementing event loop holder, it will be easy to implement get and set event loop functions. So in this week I will be implementing that.
• Week 9: Implement the run_forever and is_running functionality of the loop object.
• Week 10: Implement asyncio.sleep().
• Week 11: Work on future class and implement the basic function to create future.
• Week 12: Work on task class. As task is a subclass of future, it can be implemented only after create future has been done. So, in this week, implement the basic function to create task.

[freakboy3742]

Hi @AasthaGupta - this is a good start, but it needs a lot more detail. As I indicated during our call:

• The timeline needs to be on a week-by-week granularity.

• "Writing tests and documentation" should not be a line item - tests and documentation are an integral part of writing code, and can't be separated.

• Line items like "Implement Real time message passing" doesn't indicate that you have any understanding of the underlying problems that need to be solved.

The timeline needs to be built up from the work that needs to be done, not reverse engineered by slicing up 12 weeks and allocating to the work that needs to be done. The final proposal will be about 3 pages in length, not 3 paragraphs.

[freakboy3742]

@AasthaGupta This is much better, but still needs work.

You've started to identify the key parts that will be needed in an asyncio implementation; however, there's a lot of "hand waving" when it comes to the details. In particular, you've identified the Python side of the API... but what about the Javascript side? How are you planning to implement an event loop? Will you be using any Javascript primitives? Which ones?

In terms of ordering - will you be able to implement the opcodes before you've implemented the event loop? What will the opcode implementation look like if you haven't got an event loop to utilise? Are you going to be able to implement an awaitable WITH statement... when you haven't got basic awaiting capability implemented?

In terms of time allocation - we're looking for a specific allocation of work, on a week by week basis. This proposal still includes a 3 week block that implements "all these functions". In an ideal world, if this project was accepted, I should be able to walk into our weekly meeting, and use your schedule as a checklist for the work you've done that week (in reality, it definitely won't work out like that, but that's the theory).

In terms of complexity - have you looked into the complexity associated with Futures and Tasks? Are they any more or less complex than an event loop? This proposal makes it sound like they're "just another function"... is that really the case? The purpose of this proposal is for you to convince us that you have investigated this project in enough detail to know what you're getting involved with. Based on this proposal, I can see you've looked over the code for asyncio and identified the key parts; but I'm not convinced you've fully dug into the internals to understand what needs to be built, and in what order they need to be built.

Lastly, your schedule only allocates 9 weeks. GSoC is a 12 week program. If your proposal doesn't fill the full summer, we're actually not allowed to accept it; Google expects a full time commitment for the full GSoC period.

[AasthaGupta]

@freakboy3742 I have updated the proposal addressing the issues you pointed out in previous revision. Please take a look at it. I have looked over the asyncio code and included all the necessary details required to get started with its implementation.

• I have included the necessary details of how I will implement it.
• As this library has a lot of inter-dependencies, it will be best to have a bare-bone structure before starting with the real internal implementation of various functionalities.
• I have tried to include more details in the schedule related to weekly goals.
• Future and Tasks are complex classes but to implement the basic functionality we will be needing the basic functionality of creating them.

[freakboy3742]

@AasthaGupta Thanks - that extra detail is very helpful.

The thing that is concerning me with this proposal at this point is that you've given an entire proposal about asyncio:

• without mentioning coroutines at all,
• without mentioning any of the features in ES6 or ES2017 that support asynchronous operation, and
• without mentioning how the "unix signal" based approach to asyncio used in CPython will map to Javascript.

It feels a bit like you've looked at the modules that are involved (which is a good start), but not looked at the underlying problem to work out how it will be implemented.

Implementing asyncio isn't just a matter of porting some code - there are some fairly fundamental concepts at the core that need to be understood - but this proposal doesn't address any of those concepts.

[AasthaGupta]

@freakboy3742 I am not sure what do you mean by "Unix signal" based approach in asyncio? Is it how task resume/stop will be signalled or process signal handler? Also I have updated the proposal.

[freakboy3742]

Unfortunately, this project was not selected for the 2018 GSoC. Thanks for applying!