[issue1572968] release GIL while doing I/O operations in the mmap module
Nic Watson added the comment: I'll add one more system I/O call that's not GIL-wrapped in the mmap module that can take some time: mmap itself. mmap on Linux with MAP_POPULATE (0x8000) as the flags can take quite a bit of time. That's the flag that prefaults the memory range. MAP_POPULATE has been around since Linux 2.5.46. I know that MAP_POPULATE isn't explicitly supported in the module, but mmap.mmap does take arbitrary flags, so it isn't exactly unsupported either. -- nosy: +jnwatson ___ Python tracker <https://bugs.python.org/issue1572968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29930] Waiting for asyncio.StreamWriter.drain() twice in parallel raises an AssertionError when the transport stopped writing
Change by Nic Watson : -- nosy: +jnwatson ___ Python tracker <https://bugs.python.org/issue29930> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35945] Cannot distinguish between subtask cancellation and running task cancellation
Nic Watson added the comment: Excellent answer by twisteroid Ambassador. Resolved -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue35945> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35945] Cannot distinguish between subtask cancellation and running task cancellation
New submission from Nic Watson :
Goal: to distinguish inside a CancelledError exception handler whether the
current running task is being cancelled, or another task that the current task
is pending on was cancelled.
Example:
import asyncio
async def task2func():
await asyncio.sleep(2)
async def task1func(task2):
try:
await task2
except asyncio.CancelledError:
print("I don't know if I got cancelled")
async def main():
loop = asyncio.get_event_loop()
task2 = loop.create_task(task2func())
task1 = loop.create_task(task1func(task2))
await asyncio.sleep(0.5)
print('Cancelling first task')
task1.cancel()
await task1
await asyncio.sleep(0.5)
task2 = loop.create_task(task2func())
task1 = loop.create_task(task1func(task2))
await asyncio.sleep(0.5)
print('Cancelling second task')
task2.cancel()
await task1
asyncio.run(main())
If I have a task1 waiting on a task2, there's no public method (that I can
tell) available in the task1func exception handler to distinguish between
whether task1 or task2 were cancelled.
There is an internal field task_must_cancel in the C task struct that could be
used to interrogate one's own current task to see if it is being cancelled. It
is not available from Python (without ctypes hacking). The Python
implementation's equivalent is called _must_cancel. (I'm not sure it is a good
idea to export this from an API design perspective, but it does mean a
mechanism exists.)
A workaround is that one can explicitly add attributes to the Python task
object to communicate that a task is *starting to* be cancelled. This field
would have the same purpose as the task_must_cancel field.
--
components: asyncio
messages: 335108
nosy: asvetlov, jnwatson, yselivanov
priority: normal
severity: normal
status: open
title: Cannot distinguish between subtask cancellation and running task
cancellation
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue35945>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30945] loop.create_server does not detect if the interface is IPv6 enabled
Change by Nic Watson : -- nosy: +jnwatson ___ Python tracker <https://bugs.python.org/issue30945> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34680] asyncio event_loop close fails off main thread if signal handler registered
New submission from Nic Watson : If a signal handler callback is registered on an event loop, and the event loop has close() called on it, the close will fail. Exception: Exception in thread Thread-1: Traceback (most recent call last): File "/home/nic/.pyenv/versions/3.7.0/lib/python3.7/threading.py", line 917, in _bootstrap_inner self.run() File "/home/nic/.pyenv/versions/3.7.0/lib/python3.7/threading.py", line 865, in run self._target(*self._args, **self._kwargs) File "/home/nic/tmp/signal_event_loop_bug.py", line 9, in do_loop loop.close() File "/home/nic/.pyenv/versions/3.7.0/lib/python3.7/asyncio/unix_events.py", line 58, in close self.remove_signal_handler(sig) File "/home/nic/.pyenv/versions/3.7.0/lib/python3.7/asyncio/unix_events.py", line 147, in remove_signal_handler signal.signal(sig, handler) File "/home/nic/.pyenv/versions/3.7.0/lib/python3.7/signal.py", line 47, in signal handler = _signal.signal(_enum_to_int(signalnum), _enum_to_int(handler)) ValueError: signal only works in main thread Code: import asyncio import signal import threading def mysighandler(): pass def do_loop(loop): loop.close() loop = asyncio.new_event_loop() loop.add_signal_handler(signal.SIGINT, mysighandler) t = threading.Thread(target=do_loop, args=(loop,)) t.start() t.join() -- components: asyncio messages: 325354 nosy: asvetlov, jnwatson, yselivanov priority: normal severity: normal status: open title: asyncio event_loop close fails off main thread if signal handler registered type: behavior versions: Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue34680> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34679] asyncio.add_signal_handler call fails if not on main thread
New submission from Nic Watson : Summary: essentially asyncio.add_signal_handler doesn't work when called off the main thread. One might consider this a documentation failure. (Note: there's also a bigger issue with cleanup, which I'll submit separately) Exception in thread Thread-1: Traceback (most recent call last): File "/home/nic/.pyenv/versions/3.6.4/lib/python3.6/asyncio/unix_events.py", line 91, in add_signal_handler signal.set_wakeup_fd(self._csock.fileno()) ValueError: set_wakeup_fd only works in main thread During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/nic/.pyenv/versions/3.6.4/lib/python3.6/threading.py", line 916, in _bootstrap_inner self.run() File "/home/nic/.pyenv/versions/3.6.4/lib/python3.6/threading.py", line 864, in run self._target(*self._args, **self._kwargs) File "/home/nic/tmp/signal_event_loop_bug.py", line 14, in do_loop loop.add_signal_handler(signal.SIGINT, mysighandler) File "/home/nic/.pyenv/versions/3.6.4/lib/python3.6/asyncio/unix_events.py", line 93, in add_signal_handler raise RuntimeError(str(exc)) RuntimeError: set_wakeup_fd only works in main thread Code: import asyncio import signal import threading def mysighandler(): pass def do_loop(): loop = asyncio.new_event_loop() # This will fail with RuntimeError: set_wakeup_fd only works in main thread loop.add_signal_handler(signal.SIGINT, mysighandler) loop.close() t = threading.Thread(target=do_loop) t.start() t.join() -- components: asyncio messages: 325350 nosy: asvetlov, jnwatson, yselivanov priority: normal severity: normal status: open title: asyncio.add_signal_handler call fails if not on main thread type: behavior versions: Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue34679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34349] asyncio.wait should accept generator of tasks as first argument
New submission from Nic Watson : Currently, passing a generator of coroutines or futures as the first parameter of asyncio.wait raises a TypeError. This is in conflict with the documentation calling the first parameter a "sequence". Line in question. https://github.com/python/cpython/blob/3.7/Lib/asyncio/tasks.py#L347 Generators are indeed coroutines, so the check to validate that the first parameter is not a coroutine or a future is too specific. I'd suggest replacing that line with a check that the passed-in parameter is iterable, i.e. hasattr(futures, __iter__). -- components: asyncio messages: 323217 nosy: asvetlov, jnwatson, yselivanov priority: normal severity: normal status: open title: asyncio.wait should accept generator of tasks as first argument versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34349> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29729] UUID bytes constructor has too-tight an assertion
New submission from Nic Watson: The assertion: File "/usr/lib/python3.6/uuid.py", line 150, in __init__ assert isinstance(bytes, bytes_), repr(bytes) is too specific (and IMHO, unpythonic). One may want to pass a bytearray or a memoryview. See int.from_bytes for an example that takes "bytes" but accepts anything that acts like a bytes. A simple solution may be to delete the assertion (it worked for me). Example code: import uuid b = uuid.uuid1().bytes ba = bytearray(b) print(uuid.UUID(bytes=b)) # another API that works similarly, accepts a bytearray print(int.from_bytes(ba, byteorder='big')) # fails on assertion print(uuid.UUID(bytes=ba)) -- components: Extension Modules messages: 289045 nosy: jnwatson priority: normal severity: normal status: open title: UUID bytes constructor has too-tight an assertion type: behavior versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29729> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
