[Python-Dev] Importance of "async" keyword
Chris Angelico
rosuav at gmail.com
Fri Jun 26 18:20:17 CEST 2015
More information about the Python-Dev mailing list
Fri Jun 26 18:20:17 CEST 2015
- Previous message (by thread): [Python-Dev] Importance of "async" keyword
- Next message (by thread): [Python-Dev] Importance of "async" keyword
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sat, Jun 27, 2015 at 2:07 AM, R. David Murray <rdmurray at bitdance.com> wrote: > On Sat, 27 Jun 2015 01:10:33 +1000, Chris Angelico <rosuav at gmail.com> wrote: >> The way I'm seeing it, coroutines are like cooperatively-switched >> threads; you don't have to worry about certain operations being >> interrupted (particularly low-level ones like refcount changes or list >> growth), but any time you hit an 'await', you have to assume a context >> switch. That's all very well, but I'm not sure it's that big a problem >> to accept that any call could context-switch; atomicity is already a >> concern in other cases, which is why we have principles like EAFP >> rather than LBYL. > > Read Glyph's article, it explains why: > > https://glyph.twistedmatrix.com/2014/02/unyielding.html Makes some fair points, but IMO it emphasizes what I'm saying about atomicity. If you really need it, establish it by something other than just having code that naively progresses through. That's what databasing is for, after all. Threading and signals force you to think about concurrency; other models *may* allow you to pretend it doesn't exist. Anyway, that answers my question about why the explicit "this can let other things run" marker. Thanks all. ChrisA
- Previous message (by thread): [Python-Dev] Importance of "async" keyword
- Next message (by thread): [Python-Dev] Importance of "async" keyword
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list