[issue37355] SSLSocket.read does a GIL round-trip for every 16KB TLS record
Safihre added the comment: Implementing for write is not needed as OpenSSL's SSL_write_ex that is used by write() already writes the whole buffer at once. Only reading OpenSSL does in the 16k segments. The new option was introduced to prevent the compatibility problems for code that would not expect the EOF being read in a sinhle read(), as Josh explained in his initial PR. This way the faster (but breaking) behavior can be enabled explicitly. The info is also in the PR, in case there is time to review in the future. -- ___ Python tracker <https://bugs.python.org/issue37355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37355] SSLSocket.read does a GIL round-trip for every 16KB TLS record
Safihre added the comment: Pinging in hope for a review on https://github.com/python/cpython/pull/31492 -- ___ Python tracker <https://bugs.python.org/issue37355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37355] SSLSocket.read does a GIL round-trip for every 16KB TLS record
Safihre added the comment: Could the new PR be reviewed? Thank you! https://github.com/python/cpython/pull/31492 Documentation still needs updating, but would like feedback. PS: Why not enable the setting the GitHub Actions workflow only need to be approved for new GitHub accounts instead of for *all* new contributors? -- ___ Python tracker <https://bugs.python.org/issue37355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37355] SSLSocket.read does a GIL round-trip for every 16KB TLS record
Change by Safihre : -- pull_requests: +29622 pull_request: https://github.com/python/cpython/pull/31492 ___ Python tracker <https://bugs.python.org/issue37355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37355] SSLSocket.read does a GIL round-trip for every 16KB TLS record
Safihre added the comment: Is anyone available to give feedback on the remaining questions/problems in the PR? I don't want to be pushy and if it's only changed in 3.11, I understand, but just hoping for some progress :) Also willing to dive into it myself, but not a network/python-core specialist to really get all the details right away. -- ___ Python tracker <https://bugs.python.org/issue37355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37355] SSLSocket.read does a GIL round-trip for every 16KB TLS record
Safihre added the comment: Understandable, as the feature freeze was yesterday :) Just like to note that we have a 100.000 or so users (which I know is very little compared to overal number of Python users) of our application that this could really help. We have used a lot of CPU cycles over the past year doing many repeated 'recv(16384)' for SSL-sockets. Thank you! -- ___ Python tracker <https://bugs.python.org/issue37355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37355] SSLSocket.read does a GIL round-trip for every 16KB TLS record
Safihre added the comment: It would be very beneficial if this gets added. In our application (usenet client) I have wondered for years why we had to limit ourselves to 16k blocks and have such lower speeds compared to non SSL connections. -- nosy: +Safihre ___ Python tracker <https://bugs.python.org/issue37355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43638] MacOS os.statvfs() has rollover for >4TB disks at each 4TB (32bit counter overflow?)
Change by Safihre : -- nosy: +Safihre ___ Python tracker <https://bugs.python.org/issue43638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41705] os.makedirs fails on long-path UNC-paths if it is the first sub-folder
Change by Safihre : -- title: os.makedirs fails long-path UNC-paths if it is the first sub-folder -> os.makedirs fails on long-path UNC-paths if it is the first sub-folder type: -> crash ___ Python tracker <https://bugs.python.org/issue41705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41705] os.makedirs fails long-path UNC-paths if it is the first sub-folder
New submission from Safihre :
It consistently fails on the first directory in a long-path UNC notation
server-folder.
>>> os.makedirs(r"\\?\UNC\DiskStation\already_exists", exist_ok=True)
Traceback (most recent call last):
File "", line 1, in
File "C:\Users\safihre\AppData\Local\Programs\Python\Python38\lib\os.py",
line 213, in makedirs
makedirs(head, exist_ok=exist_ok)
File "C:\Users\safihre\AppData\Local\Programs\Python\Python38\lib\os.py",
line 213, in makedirs
makedirs(head, exist_ok=exist_ok)
File "C:\Users\safihre\AppData\Local\Programs\Python\Python38\lib\os.py",
line 223, in makedirs
mkdir(name, mode)
OSError: [WinError 123] The filename, directory name, or volume label syntax is
incorrect: '?\\UNC\\'
>>> os.makedirs(r"\\?\UNC\DiskStation\already_exists")
Traceback (most recent call last):
File "", line 1, in
File "C:\Users\safihre\AppData\Local\Programs\Python\Python38\lib\os.py",
line 213, in makedirs
makedirs(head, exist_ok=exist_ok)
File "C:\Users\safihre\AppData\Local\Programs\Python\Python38\lib\os.py",
line 213, in makedirs
makedirs(head, exist_ok=exist_ok)
File "C:\Users\safihre\AppData\Local\Programs\Python\Python38\lib\os.py",
line 223, in makedirs
mkdir(name, mode)
OSError: [WinError 123] The filename, directory name, or volume label syntax is
incorrect: '?\\UNC\\'
The second level directory is working correctly as expected:
>>> os.makedirs(r"\\?\UNC\DiskStation\already_exists\new")
>>> os.makedirs(r"\\?\UNC\DiskStation\already_exists\new")
Traceback (most recent call last):
File "", line 1, in
File "C:\Users\safihre\AppData\Local\Programs\Python\Python38\lib\os.py",
line 223, in makedirs
mkdir(name, mode)
FileExistsError: [WinError 183] Cannot create a file when that file already
exists: '?\\UNC\\DiskStation\\test_get2\\test2'
Inspecting the code, I think the problem is in the os.path.exists function that
is called from within os.makedirs, the line in os.makedirs says:
if head and tail and not path.exists(head):
But:
>>> head, tail = path.split(r"\\?\UNC\DiskStation\already_exists")
('?\\UNC\\DiskStation', 'already_exists')
>>> os.path.exists(r'\\?\UNC\DiskStation')
False
>>> os.path.exists(r'\\DiskStation')
False
So it wrongly goes ahead and tries to create \\?\UNC\DiskStation
--
components: Windows
messages: 376312
nosy: Safihre, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.makedirs fails long-path UNC-paths if it is the first sub-folder
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue41705>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31122] SSLContext.wrap_socket() throws OSError with errno == 0
Safihre added the comment: Would anyone be able to review this? People keep reporting this bug in my project. Months are just passing while the PR is just a few lines of code: https://github.com/python/cpython/pull/18772/files -- ___ Python tracker <https://bugs.python.org/issue31122> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31122] SSLContext.wrap_socket() throws OSError with errno == 0
Safihre added the comment: In the CherryPy project it is also observed on Windows with Python 3,7.2. In CherryPy it's triggered by Checker plugin, which connects to the app listening to the socket port in TLS mode via plain HTTP during startup (from the same process). It has been around for a while: https://github.com/cherrypy/cherrypy/issues/1618#issuecomment-454150794 -- nosy: +Safihre ___ Python tracker <https://bugs.python.org/issue31122> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1759845] subprocess.call fails with unicode strings in command line
Safihre <safi...@sabnzbd.org> added the comment: Although this issue is very old, in case anyone else like us need this functionality I created a package that implements the proposed C-fix. https://pypi.python.org/pypi/subprocessww Simply "import subprocessww" and POpen is patched. We tested it and it does the job pretty well, haven't run into special situations yet. We really want to upgrade our app to Python 3, but currently lack the manpower to go over our app line by line. It's not a simple 2to3 conversion, unfortunately. ------ nosy: +Safihre ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue1759845> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31555] Windows pyd slower when not loaded via load_dynamic
Safihre <safi...@sabnzbd.org> added the comment: If you know the problem, would you also know the solution? What is the difference in how they generate sys.path entries and how does this affect performance during execution of the module function? Just want to understand what is going on :) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31555> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31555] Windows pyd slower when not loaded via load_dynamic
Safihre <safi...@sabnzbd.org> added the comment: Very good question! 5000 times via imp.load_dynamic: yEnc C New took 5870 ms yEnc C New took 5878 ms yEnc C New took 5835 ms 5000 times via "pip: having the .pyd in site-packages" yEnc C New took 6489 ms yEnc C New took 6369 ms yEnc C New took 6390 ms Difference ~450 ms 1 times via imp.load_dynamic: yEnc C New took 11775 ms yEnc C New took 11720 ms yEnc C New took 11695 ms 1 times via "pip: having the .pyd in site-packages" yEnc C New took 12338 ms yEnc C New took 12281 ms yEnc C New took 12345 ms Difference ~500 ms 1 times via imp.load_dynamic: yEnc C New took 23431 ms yEnc C New took 23406 ms yEnc C New took 23283 ms 1 times via "pip: having the .pyd in site-packages" yEnc C New took 24401 ms yEnc C New took 24177 ms yEnc C New took 24482 ms Difference ~1100 ms So not very linearly scaling but still increasing. Odd. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31555> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31555] Windows pyd slower when not loaded via load_dynamic
Change by Safihre <safi...@sabnzbd.org>: -- resolution: third party -> ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31555> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31555] Windows pyd slower when not loaded via load_dynamic
Safihre <safi...@sabnzbd.org> added the comment: No, the difference is not wheel vs setuptools. They both generate the identical pyd file. The difference is python: if the module is loaded by just being available on the path or if the module is loaded via imp.load_dynamic I understand if it's closed because it's not python 3, but it's not external tool related. -- status: closed -> open ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31555> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31555] Windows pyd slower when not loaded via load_dynamic
New submission from S Safihre: I have a Python 2.7 C-extension that was made for performance, however, I noticed something strange on Windows: When I run locally python setup.py install and it installs it the "egg" way, the performance of calling the function in the module 500x in a loop is: yEnc C New took 579 ms yEnc C New took 580 ms yEnc C New took 580 ms But when I install it as a wheel locally or via pip without a single change to the C-code, this is the result: yEnc C New took 702 ms yEnc C New took 694 ms yEnc C New took 691 ms That's a 10-15% difference. I also checked macOS and Ubuntu, here it does not seem to be the case. By investigating (https://github.com/pypa/setuptools/issues/1154) I found that the difference is only that the "egg" way the module gets loaded via imp.load_dynamic I cannot test under Python 3, since the module is (not yet) converted to Python 3-style. To reproduce run and look at the yEnc C New score between the 2 ways (on Windows only of course): git clone https://github.com/sabnzbd/sabyenc.git cd sabyenc python setup.py install python .\tests\speed_compare.py; python .\tests\speed_compare.py;python .\tests\speed_compare.py; pip uninstall sabyenc -y pip install sabyenc # Or this: # python setup.py install bdist_wheel # pip install .\dist\sabyenc-3.3.1-cp27-cp27m-win_amd64.whl python .\tests\speed_compare.py; python .\tests\speed_compare.py;python .\tests\speed_compare.py; -- components: Extension Modules, Windows messages: 302768 nosy: S Safihre, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows pyd slower when not loaded via load_dynamic type: performance versions: Python 2.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31555> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28248] Upgrade installers to OpenSSL 1.0.2j
S Safihre added the comment: >From the changelog I interpreted this to mean that Python would now use >OpenSSL 1.0.2j on macOS for it's ssl module. But this is not the case? On a fresh macOS Sierra VM I get: Python 2.7.13rc1 (v2.7.13rc1:4d6fd49eeb14, Dec 3 2016, 13:01:23) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import ssl >>> ssl.OPENSSL_VERSION 'OpenSSL 0.9.8zh 14 Jan 2016' -- nosy: +S Safihre ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28248> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
