[issue34687] asyncio: is it time to make ProactorEventLoop as the default event loop?
Carlton Gibson added the comment: This change causes an issue in asgiref (and so Django) for Windows and Python 3.8. https://github.com/django/asgiref/issues/132 https://code.djangoproject.com/ticket/30900 It looks as if `ProactorEventLoop` needs to check the current thread before triggering the signal... ``` File "C:\Jenkins\workspace\django-windows\database\sqlite3\label\windows\python\Python38\.env\lib\site-packages\asgiref\sync.py", line 130, in _run_event_loop File "C:\Python38\lib\asyncio\proactor_events.py", line 679, in close signal.set_wakeup_fd(-1) ValueError: set_wakeup_fd only works in main thread ``` ... but I'm not familiar with the internals here as yet. (I'm guessing I need to create a new issue?) -- nosy: +carltongibson ___ Python tracker <https://bugs.python.org/issue34687> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38563] Asyncio regression on Windows with Python 3.8
New submission from Carlton Gibson :
6ea29c5e90dde6c240bd8e0815614b52ac307ea1 for
https://bugs.python.org/issue34687
"Make asynico use ProactorEventLoop by default"
This introducesd a regression in asgiref, and hence Django 3.0.x.
https://github.com/django/asgiref/issues/132
https://code.djangoproject.com/ticket/30900
The error from the asgiref issue is clearest:
```
asgiref\sync.py:97: in __call__
loop_future.result()
..\..\..\AppData\Local\Programs\Python\Python38\lib\concurrent\futures\_base.py:432:
in result
return self.__get_result()
..\..\..\AppData\Local\Programs\Python\Python38\lib\concurrent\futures\_base.py:388:
in __get_result
raise self._exception
..\..\..\AppData\Local\Programs\Python\Python38\lib\concurrent\futures\thread.py:57:
in run
result = self.fn(*self.args, **self.kwargs)
asgiref\sync.py:130: in _run_event_loop
loop.close()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self =
def close(self):
if self.is_running():
raise RuntimeError("Cannot close a running event loop")
if self.is_closed():
return
> signal.set_wakeup_fd(-1)
E ValueError: set_wakeup_fd only works in main thread
```
Off the main thread, we use a ThreadPoolExecutor and wait for the future to
finish.
It looks as if `ProactorEventLoop` needs to check the current thread before
triggering the signal in close().
--
components: asyncio
messages: 355214
nosy: asvetlov, carltongibson, yselivanov
priority: normal
severity: normal
status: open
title: Asyncio regression on Windows with Python 3.8
type: crash
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue38563>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34687] asyncio: is it time to make ProactorEventLoop as the default event loop?
Carlton Gibson added the comment: Created: https://bugs.python.org/issue38563 Thanks! -- ___ Python tracker <https://bugs.python.org/issue34687> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38563] Asyncio regression on Windows with Python 3.8
Carlton Gibson added the comment: Reproduce steps, on Windows with Python 3.8.0, and a clean venv. git clone https://github.com/django/asgiref.git cd asgiref pip install -e .[tests] py.test . -- nosy: -Mariusz Felisiak ___ Python tracker <https://bugs.python.org/issue38563> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38563] ProactorEventLoop.close(): set_wakeup_fd() only works in main thread
Carlton Gibson added the comment: Thanks for the speedy patch Victor. Great effort! -- ___ Python tracker <https://bugs.python.org/issue38563> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38563] ProactorEventLoop.close(): set_wakeup_fd() only works in main thread
Carlton Gibson added the comment: OK, that seems fair :) Will do that tomorrow AM. -- ___ Python tracker <https://bugs.python.org/issue38563> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38563] ProactorEventLoop.close(): set_wakeup_fd() only works in main thread
Carlton Gibson added the comment: Super turn-around. Thank you all. -- resolution: fixed -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue38563> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43773] macOS official installer builds not respecting DYLD_LIBRARY_PATH environment variable.
New submission from Carlton Gibson :
Hi.
On MacOS 11.3 "Big Sur", with the latest 3.9.4 installed with the official
installer downloaded from python.org, the DYLD_LIBRARY_PATH environment
variable is not being respected.
This looks very similar to Issue40198
https://bugs.python.org/issue40198
To begin everything looks correct as per 40198:
~ $ python3 --version
Python 3.9.4
~ $ which python3
/Library/Frameworks/Python.framework/Versions/3.9/bin/python3
~ $ codesign --display --entitlements=:-
/Library/Frameworks/Python.framework/Versions/3.9/bin/python3
Executable=/Library/Frameworks/Python.framework/Versions/3.9/bin/python3.9
http://www.apple.com/DTDs/PropertyList-1.0.dtd";>
com.apple.security.cs.allow-dyld-environment-variables
com.apple.security.cs.disable-library-validation
com.apple.security.cs.disable-executable-page-protection
com.apple.security.automation.apple-events
The active python is that from the official installer, and it looks to have the
correct entitlements, as per the resolution to 40198.
However, it's not working in practice.
I create a script test:
~ $ cat ~/bin/sqlite_config.py
import os
import sqlite3
print("DYLD_LIBRARY_PATH:" )
print(os.getenv('DYLD_LIBRARY_PATH'))
print("SQLite Version:")
print(sqlite3.sqlite_version)
Together with a compiled SQLite version:
~ $ ls /Users/carlton/lib/sqlite/3.35.4
libsqlite3.dylib
Trying to use this, the dylib is not picked up:
~ $ DYLD_LIBRARY_PATH="/Users/carlton/lib/sqlite/3.35.4" python3
~/bin/sqlite_config.py
DYLD_LIBRARY_PATH:
/Users/carlton/lib/sqlite/3.35.4
SQLite Version:
3.34.0
Contrast the same when run with a pyenv installed python:
~ $ pyenv which python3.8
/Users/carlton/.pyenv/versions/3.8.3/bin/python3.8
~ $ DYLD_LIBRARY_PATH="/Users/carlton/lib/sqlite/3.35.4"
/Users/carlton/.pyenv/versions/3.8.3/bin/python3.8 ~/bin/sqlite_config.py
DYLD_LIBRARY_PATH:
/Users/carlton/lib/sqlite/3.35.4
SQLite Version:
3.35.4
The expected result, in both cases, is that the last lines should read:
SQLite Version:
3.35.4
I don't know if this is the result of a tightening in macOS' SIP in Big Sur (or
something else entirely...) — I thought to test it by installing the official
build in a different location (so not in the SIP protected `/Library/` space
but somewhere in `~` but the installer doesn't look like it allows that (no
doubt for good reasons).
Next step for me with be building from source to see if I can dig deeper, but I
thought I'd report it, as it does look like a change in behaviour from the
*success* reported in 40198.
Thanks very much!
--
components: macOS
messages: 390529
nosy: carltongibson, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: macOS official installer builds not respecting DYLD_LIBRARY_PATH
environment variable.
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue43773>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43773] macOS official installer builds not respecting DYLD_LIBRARY_PATH environment variable.
Carlton Gibson added the comment: Hi Ned, Thank you for the reply. That explains a lot. I hadn't considered that SQLite would be statically linked. > I believe the original reason was to avoid linking with the Apple-supplied > system copy of the sqlite3 library. I can see that being a goal, yes. It's likely a niche use-case needing to adjust the SQLite version, so … Thanks again! -- ___ Python tracker <https://bugs.python.org/issue43773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38671] pathlib.Path.resolve(strict=False) returns relative path on Windows if the entry does not exist
Change by Carlton Gibson : -- nosy: +carltongibson ___ Python tracker <https://bugs.python.org/issue38671> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37373] Configuration of windows event loop for libraries
Change by Carlton Gibson : -- nosy: +carltongibson ___ Python tracker <https://bugs.python.org/issue37373> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42775] __init_subclass__ should be called in __init__
Change by Carlton Gibson : -- nosy: +carltongibson ___ Python tracker <https://bugs.python.org/issue42775> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
