4 ms·
Been coming across lot of these issues. Asyncio requires slightly different thought processes. As soon as you have an `await` anywhere in the code, you've got
by cheez 6y ago
Been coming across lot of these issues. Asyncio requires slightly different thought processes.
As soon as you have an `await` anywhere in the code, you've got to assume that your code will be re-entered. Lots of asyncio.Locks all over the place for me.
Glad people are bringing this up. I had to learn this on my own.
- pansa2 6y ago> As soon as you have an `await` anywhere in the code, you've got to assume that your code will be re-entered. At least the re-entry points are explicitly marked with `await`. IMO that's the main benefit of async-await (stackless coroutines) over stackful coroutines or threads, which allow your code to be suspended and re-entered almost anywhere. Of course the drawback of async-await is the "function color" issue [0], in which it's difficult for functions that don't suspend to call those which do. [0] http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
- cheez 6y agoThat's a good perspective.
- nurettin 6y agoI've wrestled with this. A cleaner solution seems to be: using an asyncio.Queue. So when your function is not reentrant, params = await command.get() runs in a loop inside a task ( command.put_nowait(params) is called elsewhere) you can also use this to distribute tasks to different class methods
- cheez 6y agoI will keep this in mind!
- alpineidyll3 6y agoEvery time I find something that seems unnecessarily awk in asyncio, I eventually find out there's a good reason. But plenty of things that are written with it aren't using it exactly right.