summaryrefslogtreecommitdiffstats
path: root/Modules/_asynciomodule.c
Commit message (Collapse)AuthorAgeFilesLines
* bpo-37547: add _PyObject_CallMethodOneArg (GH-14685)Jeroen Demeyer2019-07-111-8/+6
|
* bpo-37337: Add _PyObject_CallMethodNoArgs() (GH-14267)Jeroen Demeyer2019-07-081-9/+7
|
* bpo-37483: add _PyObject_CallOneArg() function (#14558)Jeroen Demeyer2019-07-041-12/+9
|
* bpo-37194: Add a new public PyObject_CallNoArgs() function (GH-13890)Victor Stinner2019-06-171-6/+6
| | | | | | | | | | | | | | | Add a new public PyObject_CallNoArgs() function to the C API: call a callable Python object without any arguments. It is the most efficient way to call a callback without any argument. On x86-64, for example, PyObject_CallFunctionObjArgs(func, NULL) allocates 960 bytes on the stack per call, whereas PyObject_CallNoArgs(func) only allocates 624 bytes per call. It is excluded from stable ABI 3.8. Replace private _PyObject_CallNoArg() with public PyObject_CallNoArgs() in C extensions: _asyncio, _datetime, _elementtree, _pickle, _tkinter and readline.
* bpo-36999: Add asyncio.Task.get_coro() (GH-13680)Alex Grönholm2019-05-301-0/+13
| | | https://bugs.python.org/issue36999
* bpo-32388: Remove cross-version binary compatibility requirement in tp_flags ↵Antoine Pitrou2019-05-291-4/+2
| | | | | | | | (GH-4944) It is now allowed to add new fields at the end of the PyTypeObject struct without having to allocate a dedicated compatibility flag in tp_flags. This will reduce the risk of running out of bits in the 32-bit tp_flags value.
* bpo-36974: implement PEP 590 (GH-13185)Jeroen Demeyer2019-05-291-4/+2
| | | | | Co-authored-by: Jeroen Demeyer <J.Demeyer@UGent.be> Co-authored-by: Mark Shannon <mark@hotpy.org>
* bpo-32528: Make asyncio.CancelledError a BaseException. (GH-13528)Yury Selivanov2019-05-271-7/+4
| | | | | | | | | | | | | | | This will address the common mistake many asyncio users make: an "except Exception" clause breaking Tasks cancellation. In addition to this change, we stop inheriting asyncio.TimeoutError and asyncio.InvalidStateError from their concurrent.futures.* counterparts. There's no point for these exceptions to share the inheritance chain. In 3.9 we'll focus on implementing supervisors and cancel scopes, which should allow better handling of all exceptions, including SystemExit and KeyboardInterrupt
* asyncio: PendingDeprecationWarning -> DeprecationWarning (GH-12494)Inada Naoki2019-03-221-2/+2
| | | `Task.current_task()` and `Task.all_tasks()` will be removed in 3.9.
* bpo-35504: Fix segfaults and SystemErrors when deleting certain attrs. ↵Zackery Spytz2018-12-171-0/+12
| | | | (GH-11175)
* bpo-33029: Fix signatures of getter and setter functions. (GH-10746)Serhiy Storchaka2018-11-271-16/+16
| | | Fix also return type for few other functions (clear, releasebuffer).
* Fix a compiler warning added in bpo-34872. (GH-9722)Serhiy Storchaka2018-10-051-1/+1
|
* bpo-34872: Fix self-cancellation in C implementation of asyncio.Task (GH-9679)Elvis Pranskevichus2018-10-031-3/+8
| | | | | | | | | | | | | | | | | The C implementation of asyncio.Task currently fails to perform the cancellation cleanup correctly in the following scenario. async def task1(): async def task2(): await task3 # task3 is never cancelled asyncio.current_task().cancel() await asyncio.create_task(task2()) The actuall error is a hardcoded call to `future_cancel()` instead of calling the `cancel()` method of a future-like object. Thanks to Vladimir Matveev for noticing the code discrepancy and to Yury Selivanov for coming up with a pathological scenario.
* bpo-34762: Update PyContext* to PyObject* in asyncio and decimal (GH-9609)Yury Selivanov2018-09-271-9/+8
| | | This fixes various compiler warnings.
* bpo-34755: Add few minor optimizations in _asynciomodule.c. (GH-9455)Serhiy Storchaka2018-09-211-158/+116
|
* bpo-34622: Extract asyncio exceptions into a separate module (GH-9141)Andrew Svetlov2018-09-111-0/+2
|
* Fixed inconsistency in string handling in the Task C implementation (GH-8717)Alex Grönholm2018-08-091-5/+9
|
* bpo-34270: Make it possible to name asyncio tasks (GH-8547)Alex Grönholm2018-08-081-2/+58
| | | Co-authored-by: Antti Haapala <antti.haapala@anttipatterns.com>
* Make TaskStepMethWrapper_Type and TaskWakeupMethWrapper_Type static. (GH-8127)Benjamin Peterson2018-07-061-2/+2
|
* bpo-32610: Fix asyncio.all_tasks() to return only pending tasks. (GH-7174)Yury Selivanov2018-05-281-2/+2
|
* bpo-33623: Fix possible SIGSGV when asyncio.Future is created in __del__ (#7080)Yury Selivanov2018-05-281-1/+7
|
* bpo-33584: Fix several minor bugs in asyncio. (GH-7003)Serhiy Storchaka2018-05-201-15/+21
| | | | | | | | | | | | Fix the following bugs in the C implementation: * get_future_loop() silenced all exceptions raised when look up the get_loop attribute, not just an AttributeError. * enter_task() silenced all exceptions raised when look up the current task, not just a KeyError. * repr() was called for a borrowed link in enter_task() and task_step_impl(). * str() was used instead of repr() in formatting one error message (in Python implementation too). * There where few reference leaks in error cases.
* bpo-31787: Prevent refleaks when calling __init__() more than once (GH-3995)Oren Milman2018-02-131-9/+19
|
* bpo-32746: Fix multiple typos (GH-5144)Leo Arias2018-02-041-1/+1
| | | Fix typos found by codespell in docs, docstrings, and comments.
* bpo-32643: Drop support for a few private Task and Future APIs. (#5293)Yury Selivanov2018-01-241-106/+9
| | | | | | | | Specifically, it's not possible to subclass Task/Future classes and override the following methods: * Future._schedule_callbacks * Task._step * Task._wakeup
* bpo-32296: Make get_running_loop() another 4-5x faster (#5277)Yury Selivanov2018-01-231-62/+102
|
* bpo-32436: Implement PEP 567 (#5027)Yury Selivanov2018-01-231-55/+154
|
* Fix typo (#5049)Andrew Svetlov2017-12-301-1/+1
|
* bpo-31721: Allow Future._log_traceback to only be set to False (#5009)Yury Selivanov2017-12-251-0/+5
|
* bpo-32363: Disable Task.set_exception() and Task.set_result() (#4923)Yury Selivanov2017-12-251-9/+42
|
* bpo-32415: Fix "error is already set" (#4999)Yury Selivanov2017-12-231-0/+1
|
* bpo-32357: Use PySet_GET_SIZE macro in _is_coroutine() from _asynciomodule.c ↵Andrew Svetlov2017-12-231-1/+1
| | | | (#4990)
* bpo-32415: Add asyncio.Task.get_loop() and Future.get_loop() (#4992)Yury Selivanov2017-12-231-29/+69
|
* Fix GCC warning in _asynciomodule.c (#4928)Zackery Spytz2017-12-191-1/+1
|
* bpo-32357: Optimize asyncio.iscoroutine() for non-native coroutines (#4915)Yury Selivanov2017-12-191-28/+85
|
* bpo-32348: Optimize asyncio.Future schedule/add/remove callback. (#4907)Yury Selivanov2017-12-181-75/+322
|
* bpo-32250: Implement asyncio.current_task() and asyncio.all_tasks() (#4799)Andrew Svetlov2017-12-161-110/+260
|
* bpo-32311: Implement asyncio.create_task() shortcut (#4848)Andrew Svetlov2017-12-151-1/+28
| | | | | * Implement functionality * Add documentation
* bpo-32296: Implement asyncio.get_event_loop and _get_running_loop in C. (#4827)Yury Selivanov2017-12-131-7/+244
| | | | | | | | asyncio.get_event_loop(), and, subsequently asyncio._get_running_loop() are one of the most frequently executed functions in asyncio. They also can't be sped up by third-party event loops like uvloop. When implemented in C they become 4x faster.
* bpo-31185: Fixed miscellaneous errors in asyncio speedup module. (#3076)Serhiy Storchaka2017-09-031-207/+206
|
* bpo-31061: fix crash in asyncio speedup module (GH-2966)Alexander Mohr2017-08-021-0/+4
|
* bpo-30828: Fix out of bounds write in ↵Yury Selivanov2017-07-051-3/+10
| | | | `asyncio.CFuture.remove_done_callback() (#2569)
* bpo-30508: Don't log exceptions if Task/Future "cancel()" method called (#2050)Yury Selivanov2017-06-111-1/+17
|
* bpo-30048: asyncio: fix Task.cancel() was ignored. (GH-1097)INADA Naoki2017-05-111-0/+12
| | | | | | | | | | | | when there are no more `await` or `yield (from)` before return in coroutine, cancel was ignored. example: async def coro(): asyncio.Task.current_task().cancel() return 42 ... res = await coro() # should raise CancelledError
* bpo-28963: Fix out of bound iteration in ↵Yury Selivanov2017-03-031-1/+1
| | | | asyncio.Future.remove_done_callback/C (#408)
* bpo-29271: Fix Task.current_task and Task.all_tasks to accept None. (#406)Yury Selivanov2017-03-031-6/+6
|
* 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.
generated by cgit v0.12 at 2025-09-27 14:05:29 (GMT)