Re: [python-tulip] Process + Threads + asyncio... has sense?

Thank you for your responses. The scenario (I forgot in my first post): I'm trying to improve I/O accesses (disk/network...). So, if a Python thread map with a OS 1:1 thread, and the main problem (I understood that) is the cost of context switching between of threads/coroutines... this raises

Re: [python-tulip] Process + Threads + asyncio... has sense?

On Mon, Apr 18, 2016 at 1:26 PM, Imran Geriskovan < imran.gerisko...@gmail.com> wrote: > A) Python threads are not real threads. It multiplexes "Python Threads" > on a single OS thread. (Guido, can you correct me if I'm wrong, > and can you provide some info on multiplexing/context switching of >

Re: [python-tulip] Process + Threads + asyncio... has sense?

>>> I don't think you need the threads. >>> 1. If your tasks are I/O bound, coroutines are a safer way to do things, >>> and probably even have better performance; >> >> Thread vs Coroutine context switching is an interesting topic. >> Do you have any data for comparison? > My 2cts: > OS native

Re: [python-tulip] Process + Threads + asyncio... has sense?

Am 18.04.2016 um 21:33 schrieb Imran Geriskovan: On 4/18/16, Gustavo Carneiro wrote: I don't think you need the threads. 1. If your tasks are I/O bound, coroutines are a safer way to do things, and probably even have better performance; Thread vs Coroutine context

Re: [python-tulip] Process + Threads + asyncio... has sense?

On 4/18/16, Gustavo Carneiro wrote: > I don't think you need the threads. > 1. If your tasks are I/O bound, coroutines are a safer way to do things, > and probably even have better performance; Thread vs Coroutine context switching is an interesting topic. Do you have any

Re: [python-tulip] Process + Threads + asyncio... has sense?

I don't think you need the threads. 1. If your tasks are I/O bound, coroutines are a safer way to do things, and probably even have better performance; 2. If your tasks are CPU bound, only multiple processes will help, multiple (Python) threads do not help at all. Only in the special case where

[python-tulip] Process + Threads + asyncio... has sense?

Hi all, It's the first time I write in this list. Sorry if it's not the best place for this question. After I read the Asyncio's documentation, PEPs, Guido/Jesse/David Beazley articles/talks, etc, I developed a PoC library that mixes: Process + Threads + Asyncio Tasks, doing an scheme like

Re: [python-tulip] A mix of zip and select to iterate over multiple asynchronous iterator ?

What people typically do when handling multiple events is to have separate event handlers for each event type. You can do this using callbacks (typically by using the Protocol/Transport convention), or you can have separate loops that each use `await`, `async for` (or some 3.4-compatible

[python-tulip] aiomas 1.0.0 released

Hi all, I just release version 1.0.0 of aiomas (https://aiomas.readthedocs.org/) – a library for networking, RPC and multi-agent systems based on asyncio. Its basic set of features: - Three layers of abstraction around raw TCP / Unix domain sockets: - Request-reply channels -

[python-tulip] A mix of zip and select to iterate over multiple asynchronous iterator ?

> > Hi there, For a pet projet of mine (https://github.com/julienpalard/theodoreserver) I encontered a problem: I was having two asynchronous iterables (easily iterables via a simple "async for ..."), without "theodore" knowledge you can simply imagine listening for events from different