I'd suggest picking Apache 2.0

I just had a quick try with tokio, I'm currently getting a slightly speed up (~5%) compared to asyncio loop, but significantly less quick than uvloop. Is that to be expected at this stage?

Also your readme refer to tokio.EventLoopPolicy() which is wrong, as of pypi v0.1.0 the policy is called tokio.TokioLoopPolicy()

We now use new python binding https://github.com/PyO3/PyO3
it is based on rust-cpython, but whole class generation has been significantly redesigned
now code looks more like rust and not like some kind of python:

#[py:class]
pub struct Socket {
  connected: bool
}

#[py:proto]
impl PyIterProtocol for Socket {
  fn __iter__(&self, py: Python) -> PyResult<PyObject> {
  }
}

#[py:proto]
impl PyAsyncProtocol for Socket {
  fn __await__(&self, py: Python) -> PyResult<PyObject> {
  }
}

most of class functionality of already implemented, everything else should be completed within next week

Hey, this is great. It's exactly what I need for a project I'm working on. Is there any documentation or examples on how to use it in a project using Rust code with tokio that calls python with asyncjo/aiohttp? Thanks much.

While working on uvloop I've iterated on the following three different approaches to how get_extra_info('socket') should be implemented:

1. Wrap the underlying socket FD into a Python socket object: socket.socket(fileno=FD). The downside of this approach is that Python will try to control the FD. For instance, when the socket object is GCed, Python will try to close the FD, which isn't acceptable for uvloop and asyncio-tokio. Moreover, beginning with Python 3.6 there is a race to who closes the socket first, and Python expects to win, otherwise it will raise an IOError in socket.close().

2. Duplicate the FD before wrapping (currently implemented in uvloop). This fixes (1), but has its own downsides: FDs are a limited resource and now we need 2x of them; FDs can stay alive longer than necessary (if the transport is closed, but its duplicated sockets are alive).

3. Return a socket-like object. Essentially, the object should implement all socket.socket methods and have all of its attributes (to be duck-type compatible), but the implementation of socket.close() and socket.shutdown() will be empty (or will raise an error).

The third option is the one I want to implement in uvloop, and I believe the one we need to implement for asyncio-tokio.

I noticed exceptions does not contain right traceback.

what classes should support weakrefs? PyHandle, PyTimerHandler needs to support for sure. what about Future and Task objects?

should we provide python module with async-tokio? at the moment async-tokio is rust crate, to run event loop aiohttp-tokio is required.

what type PyFuture should resolve to?

currently, Future::Item is PyResult<PyObject> and Future::Err is unsync::oneshot::Cancelled

future handling code looks like:

PyFuture::new(...).map(|res: PyResult<PyObject>| {
    match res {
        Ok(obj) => "do something with result (PyObject)"
        Err(err) => "do something with py exception"
    }
}).map_err(|err| "cancelled");

other option is to use PyObject as Future::Item and PyErr as Future::Err:

PyFuture::new(...).map(|res: PyObject| {
    "do something with result (PyObject)"
}).map_err(|err| {
    "do something with py exception"
);

I like second option, but there would be no explicit cancelation state

Proposed header:

# Copied from the uvloop project.  If you add a new unittest here,
# please consider contributing it to the uvloop project.
#
# Portions copyright (c) 2015-present MagicStack Inc.  http://magic.io

If I add a signal handler for SIGINT in pure asyncio and uvloop implementation, a ctrl-c is handled by the handler in contrast to tokio, where still a KeyboardInterrupt is raised.

I use Python 3.6.3 and tokio bbf9be4.

When I send SIGINT via kill -s INT <pid> tokio raises also a KeyboardInterrupt in contrast to asyncio and uvloop.

It seems that SIGINT handler is not recognized at all...

As opposed to asyncio, which relies on mock tests a lot, uvloop contains a good number of functional unittests. They cross-test uvloop and asyncio to ensure full compatibility.

async-tokio already uses tokio-signal crate for ctrl-c handling
should be easy to extend to all signals

current implementation is based on asyncio.unix_events, we need native rust implementation

does not work at the moment

• aio-libs/aiorwlock#35 passes
• aio-libs/aiomonitor#41 fails

(tokio) rocklobster:~/python/tokio $ python setup.py build
running build
running build_py
running egg_info
writing tokio.egg-info/PKG-INFO
writing dependency_links to tokio.egg-info/dependency_links.txt
error[E0308]: mismatched typesio.egg-info/top_level.txt
  --> /home/name/.cargo/git/checkouts/pyo3-a22e69bc62b9f0fd/68937db/src/objects/string.rs:54:21
   |> /home/name/.cargo/git/checkouts/pyo3-a22e69bc62b9f0fd/68937db/src/objects/string.rs:53:21
   = note: expected type `*const u8`tr() as *const i8)) pyo3/python3 pyo3/extension-module --release -- --crate-type cderror: aborting due to 2 previous errors^^^^^^^^^^^^^ expected u8, found i8
error: cargo failed with code: 101^^^^^^^^^^^^^^^^^^^^^ expected u8, found i8
To learn more, run the command again with --verbose.

Python 3.6.3
rustc 1.23.0-nightly (827cb0d61 2017-11-26)
aarch64

looks like a solvable issue, just haven't hit the source yet.

loop.current_task() was never a part of asyncio API.
Starting from 3.7 third party loops can use dedicated calls for custom task implementation:
asyncio._register_task, ``asyncio._unregister_task, asyncio._enter_task`, `asyncio._leave_task`.

The API calls are started from underscore to emphasize these very low level position (should be used by libraries like tokio only) but they are a part of of official API.

problem described here aio-libs/aiohttp#1883

uvloop works fine

I don’t think this project makes sense.

I think we should archive it.

@konstin @althonos

https://github.com/PyO3/tokio/blob/master/tokio/__init__.py#L9

import asyncio
import tokio

asyncio.set_event_loop_policy(tokio.EventLoopPolicy())

loop = tokio.new_event_loop()
asyncio.set_event_loop(loop)

class Empty(object):
    pass

# This not work!
loop.xyz = Empty()

tokio-tls is already included and ssl is supported for "open_connection()" api.

asyncio's future ans task are not allowed at the moment.

I implemented create_server() method before added async getaddrinfo(), so right now
create_server() resolves addresses synchronously.

If I register a signal handler within a task to cancel itself, tokio failes with:
AttributeError: 'NoneType' object has no attribute 'cancel'

async def test_tokio_failes():
    current_task = asyncio.Task.current_task()
    asyncio.get_event_loop().add_signal_handler(signal.SIGINT, current_task.cancel)

def main():
    # ...
    loop.run_until_complete(test_tokio_failes())

https://docs.python.org/3/library/stdtypes.html#bytes.split

current implementation is based on asyncio.unix_events, we need native rust pipes support

exception_handler api is implemented, but rust level logging is not defined.
should we use python logging? or rust "log" or "slog" crates and separately define logging configuration api.

As the title says.

Same as like this: https://github.com/MagicStack/uvloop

we need this for some options, like TCP_NODELAY, TCP_CORK, SO_KEEPALIVE