summaryrefslogtreecommitdiffstats
path: root/Modules/_asynciomodule.c
Commit message (Collapse)AuthorAgeFilesLines
* Use _PyObject_CallMethodIdObjArgs() in _asyncioVictor Stinner2016-12-091-17/+19
| | | | | | | | | Issue #28915: Replace _PyObject_CallMethodId() with _PyObject_CallMethodIdObjArgs() when the format string was only made of "O" formats, PyObject* arguments. _PyObject_CallMethodIdObjArgs() avoids the creation of a temporary tuple and doesn't have to parse a format string.
* Use _PyObject_CallNoArg()Victor Stinner2016-12-061-1/+1
| | | | | | | Replace: PyObject_CallFunctionObjArgs(callable, NULL) with: _PyObject_CallNoArg(callable)
* Use _PyObject_CallNoArg()Victor Stinner2016-12-061-6/+6
| | | | | | | Replace: PyObject_CallObject(callable, NULL) with: _PyObject_CallNoArg(callable)
* Issue #28858: Remove _PyObject_CallArg1() macroVictor Stinner2016-12-051-3/+3
| | | | | | | | | | | Replace _PyObject_CallArg1(func, arg) with PyObject_CallFunctionObjArgs(func, arg, NULL) Using the _PyObject_CallArg1() macro increases the usage of the C stack, which was unexpected and unwanted. PyObject_CallFunctionObjArgs() doesn't have this issue.
* Backed out changeset b9c9691c72c5Victor Stinner2016-12-041-5/+7
| | | | | | Issue #28858: The change b9c9691c72c5 introduced a regression. It seems like _PyObject_CallArg1() uses more stack memory than PyObject_CallFunctionObjArgs().
* Merge 3.6 (issue #28843)Yury Selivanov2016-12-011-0/+5
|
* Replace PyObject_CallFunctionObjArgs() with fastcallVictor Stinner2016-12-011-7/+5
| | | | | | | | | | | | | | * PyObject_CallFunctionObjArgs(func, NULL) => _PyObject_CallNoArg(func) * PyObject_CallFunctionObjArgs(func, arg, NULL) => _PyObject_CallArg1(func, arg) PyObject_CallFunctionObjArgs() allocates 40 bytes on the C stack and requires extra work to "parse" C arguments to build a C array of PyObject*. _PyObject_CallNoArg() and _PyObject_CallArg1() are simpler and don't allocate memory on the C stack. This change is part of the fastcall project. The change on listsort() is related to the issue #23507.
* correctly emulate error semantics of gen.throw in FutureIter_throwBenjamin Peterson2016-11-141-19/+34
|
* Issue #26081: Fix refleak in _asyncio.Future.__iter__().throw.Yury Selivanov2016-11-091-1/+3
|
* Issue #23996: Added _PyGen_SetStopIterationValue for safe raisingSerhiy Storchaka2016-11-061-18/+4
| | | | | StopIteration with value. More safely handle non-normalized exceptions in -_PyGen_FetchStopIterationValue.
* Issue #28544: Fix inefficient call to _PyObject_CallMethodId()Victor Stinner2016-10-291-1/+1
| | | | | "()" format string creates an empty list of argument but requires extra work to parse the format string.
* Issue #28544: Pass `PyObject*` to _PyDict_Pop, not `PyDictObject*`Yury Selivanov2016-10-281-5/+5
|
* Issue #28544: Fix _asynciomodule.c on WindowsVictor Stinner2016-10-281-5/+5
| | | | | | PyType_Ready() sets the reference to &PyType_Type. &PyType_Type cannot be resolved at compilation time (not on Windows?).
* Issue #28544: Implement asyncio.Task in C.Yury Selivanov2016-10-281-277/+1699
| | | | | | | | This implementation provides additional 10-20% speed boost for asyncio programs. The patch also fixes _asynciomodule.c to use Arguments Clinic, and makes '_schedule_callbacks' an overridable method (as it was in 3.5).
* Issue #28430: Fix iterator of C implemented asyncio.Future doesn'tINADA Naoki2016-10-251-6/+4
| | | | accept non-None value is passed to it.send(val).
* Issue #28493: Fix typos in _asynciomodule.cYury Selivanov2016-10-201-2/+2
| | | | Thanks to Stéphane Wirtel!
* Issue #28492: Fix how StopIteration is raised in _asyncio.FutureYury Selivanov2016-10-201-2/+19
|
* Issue #28452: Remove _asyncio._init_module functionINADA Naoki2016-10-181-66/+55
|
* Issue #28428: Rename _futures module to _asyncio.INADA Naoki2016-10-151-0/+1034
It will have more speedup functions or classes other than asyncio.Future.
generated by cgit v0.12 at 2024-12-02 11:18:23 (GMT)