[issue22652] Add suggestion about keyword arguments to this error message: "builtins.TypeError: my_func() takes 1 positional argument but 2 were given"
A. Jesse Jiryu Davis added the comment: If the patch requires a rewrite and its value is uncertain then I'll excuse myself from this issue. -- ___ Python tracker <https://bugs.python.org/issue22652> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6721] Locks in the standard library should be sanitized on fork
Change by A. Jesse Jiryu Davis : -- nosy: -emptysquare ___ Python tracker <https://bugs.python.org/issue6721> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
A. Jesse Jiryu Davis added the comment: Here's a retelling of this bug report as a silly fantasy saga: https://engineering.mongodb.com/post/the-saga-of-concurrent-dns-in-python-and-the-defeat-of-the-wicked-mutex-troll/ -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25924> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27136] sock_connect fails for bluetooth (and probably others)
A. Jesse Jiryu Davis added the comment: Thank you Martin! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27136> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27136] sock_connect fails for bluetooth (and probably others)
A. Jesse Jiryu Davis added the comment: Thanks, I'm not a core dev or I'd try it myself. Yury, do you think that's a good approach, or should I mock getaddrinfo for that test? I fear mocking out too much and accidentally not testing anything, or of making tests that someone *else* could accidentally change so they don't test anything. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27136> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27136] sock_connect fails for bluetooth (and probably others)
A. Jesse Jiryu Davis added the comment:
Thanks Martin. That test verifies behavior that I observe in Mac OS 10.10 and
other modern platforms:
>>> socket.getaddrinfo('::2', 80, socket.AF_INET6, socket.SOCK_STREAM,
>>> socket.IPPROTO_TCP)
[(30, 1, 6, '', ('::0.0.0.2', 80, 0, 0))]
Investigating, I wrote a C program to call getaddrinfo on my Mac OS X Tiger x86
virtual machine, and indeed it resolves "::2" with family AF_INET6 in "hints"
as an IPv4 address, "0.0.0.2". However, the same setup resolves "::1" as an
IPv6 address, "::1".
Someone who knows more about IPv6 than I might guess the cause?
In any case, I wonder if replacing "::2" with "::1" at
test_base_events.py:1188, and replacing the regex '::(0\.)*2' with '::(0\.)*1'
at line 1195 would fix the test for Tiger.
Could you try that please? I'm having trouble compiling Python for Tiger so I
don't know how to test it on my virtual machine.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27136>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27136] sock_connect fails for bluetooth (and probably others)
A. Jesse Jiryu Davis added the comment: The asyncio fix was proposed and reviewed here: https://github.com/python/asyncio/pull/357 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27136> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27136] sock_connect fails for bluetooth (and probably others)
A. Jesse Jiryu Davis added the comment: I can reproduce this. On Ubuntu 14.04 I installed "libbluetooth-dev" and then built Python 3.5.1 from source, confirmed the socket module has AF_BLUETOOTH and BTPROTO_RFCOMM. Running pyptr2's script gives the traceback pyptr2 reported. Yury and I discussed a fix, which I'll propose as a patch in the asyncio GitHub repo. -- nosy: +emptysquare ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27136> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16500] Add an 'atfork' module
Changes by A. Jesse Jiryu Davis <je...@emptysquare.net>: -- nosy: +emptysquare ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16500> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6721] Locks in the standard library should be sanitized on fork
Changes by A. Jesse Jiryu Davis <je...@emptysquare.net>: -- nosy: +emptysquare ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6721> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
A. Jesse Jiryu Davis added the comment: Related to #26406, a fix for NetBSD and OpenBSD. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25924> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26406] getaddrinfo is thread-safe on NetBSD and OpenBSD
A. Jesse Jiryu Davis added the comment: Thank you! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26406> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26406] getaddrinfo is thread-safe on NetBSD and OpenBSD
A. Jesse Jiryu Davis added the comment: Patch uploaded. I've copied the "nosy" list from #25924, if that was bad etiquette please forgive me. -- keywords: +patch Added file: http://bugs.python.org/file41998/26406-getaddrinfo-netbsd-openbsd.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26406> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26406] getaddrinfo is thread-safe on NetBSD and OpenBSD
New submission from A. Jesse Jiryu Davis: In socketmodule.c we lock around getaddrinfo calls on platforms where getaddrinfo is believed not to be thread-safe. We've verified that it *is* thread-safe, and therefore stopped locking around it, on FreeBSD 5.3+ (#1288833) and Mac OS X 10.5+ (#25924). This ticket intends to do the same for OpenBSD and NetBSD. OpenBSD 5.4 fixed getaddrinfo's thread safety and announced it 2013-11-01, "getaddrinfo(3) is now thread-safe": http://www.openbsd.org/plus54.html NetBSD's fix is older and less publicized. Since ancient times NetBSD's getaddrinfo.c included a comment, "Thread safe-ness must be checked", and the getaddrinfo(3) man page had the same warning as other BSDs, "The implementation of getaddrinfo is not thread-safe." On 2004-05-27 Christos Zoulas committed with the comment "make yp stuff re-entrant", fixing obvious problems like static variables in getaddrinfo: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/net/getaddrinfo.c.diff?r1=1.71=1.72_with_tag=MAIN That change was released with NetBSD 3.0, and that alone might convince us to stop locking around getaddrinfo. Later, on 2006-07-18, between NetBSD 3 and 4, Zoulas deleted the comment "Thread safe-ness must be checked" from the source, with the message "Remove comments that do not reflect reality anymore": http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/net/getaddrinfo.c.diff?r1=1.82=1.83_with_tag=MAIN The same day, he removed the man page warning: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/net/getaddrinfo.3.diff?r1=1.43=1.44_with_tag=MAIN NetBSD 4.0 was released 2007-12-19. -- messages: 260655 nosy: emptysquare, gvanrossum, martin.panter, ned.deily, python-dev, ronaldoussoren, yselivanov priority: normal severity: normal status: open title: getaddrinfo is thread-safe on NetBSD and OpenBSD versions: Python 2.7, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26406> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
A. Jesse Jiryu Davis added the comment: I think we have consensus for "try 2". I'm not a core dev, would one of you please merge 25924-getaddrinfo-is-thread-safe-2.patch? Thanks! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25924> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
A. Jesse Jiryu Davis added the comment: Martin, here's a third patch, "try 3", which does a runtime version check instead of compile-time. It's a bit complex, compared to "try 2", which did a compile-time check instead. I do NOT think this extra complexity is worth it to support Pythons that are built on 10.5+ and running on Mac OS 10.4 and older. 10.4 is long obsolete. I propose merging "try 2" with the compile-time check. If that patch is accepted, I'll submit a patch for Python 2.7 also. Thank you! -- Added file: http://bugs.python.org/file41878/25924-getaddrinfo-is-thread-safe-3.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25924> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
A. Jesse Jiryu Davis added the comment: Thanks Martin. The MAC_OS_X_VERSION_10_5 macro ensures that Python is still compatible with Mac OS before version 10.5: if it's built on 10.4 or older, it locks around getaddrinfo (since it's not thread-safe there), and on 10.5 and later it doesn't lock. I've built on a Mac OS 10.4 virtual machine and verified we'll still use the lock on that OS. I think this is good enough, without a runtime check. We distribute prebuilt binaries for Mac OS 10.5+: https://www.python.org/downloads/release/python-2711/ So those prebuilt Pythons should no longer lock around getaddrinfo. People who still use older Mac OSes (more than 12 years old!) will have to build Python themselves in order to get recent versions of Python, since we don't distribute binaries for them any more. Since they're building Python on old Mac OS, the MAC_OS_X_VERSION_10_5 macro will be undefined and they'll keep using the getaddrinfo lock. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25924> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
A. Jesse Jiryu Davis added the comment: Second patch with a comment about how we know Mac OS 10.5+'s getaddrinfo is thread-safe. I'll wait for this to be merged before submitting another for Python 2.7. -- Added file: http://bugs.python.org/file41784/25924-getaddrinfo-is-thread-safe-2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25924> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
A. Jesse Jiryu Davis added the comment: Great, how do we ensure this gets merged soon? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25924> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
A. Jesse Jiryu Davis added the comment: I've created a Mac OS 10.4 virtual machine and reproduced the getaddrinfo concurrency bug there using the attached h_resolv.c. The man page on that OS version indeed includes the "not thread-safe" warning. The same test passes on my Mac OS 10.10 system. I am convinced that getaddrinfo is thread-safe on Mac OS 10.5+, and I'm attaching a patch to disable the lock on these systems. -- keywords: +patch Added file: http://bugs.python.org/file41755/25924-getaddrinfo-is-thread-safe.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25924> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
A. Jesse Jiryu Davis added the comment: An Apple Developer Relations engineer tells me it's "reasonable to assume that getaddrinfo() is thread safe" on OS X 10.5 and later. (He mentioned that iOS inherited the OS X 10.5 DNS architecture, so Apple phones, watches, TVs, hairdryers, etc. can all do concurrent DNS too.) Before OS X 10.5 the DNS system was a mix of new Mac OS X features, mDNSResponder and Open Directory, along with historical lookupd from NeXT and libresolv from an old BSD. In 10.5 the system was cleaned up to depend on OS X's mDNSResponder consistently; in the process getaddrinfo became thread-safe. He cites as further evidence of its thread safety: * The "bugs" section of getaddrinfo's man page was removed in 10.5 * 10.5 is the first OS X to be UNIX '03 certified, which includes the requirement that getaddrinfo be thread-safe * The system itself uses getaddrinfo extensively as if it's thread-safe * He hasn't seen reports of thread-safety problems with getaddrinfo He explained how the code works. In the latest version: http://www.opensource.apple.com/source/Libinfo/Libinfo-476/lookup.subproj/libinfo.c getaddrinfo calls down to libinfo’s "mdns" module: http://www.opensource.apple.com/source/Libinfo/Libinfo-476/lookup.subproj/mdns_module.c "mdns" uses the DNS-SD API declared in dns_sd.h, which he says is "well known to be thread safe." The DNS-SD API is part of the mDNSResponder project: http://www.opensource.apple.com/source/mDNSResponder/mDNSResponder-576.30.4/ The key function is DNSServiceQueryRecord: http://www.opensource.apple.com/source/mDNSResponder/mDNSResponder-576.30.4/mDNSShared/dnssd_clientstub.c My contact concludes, "As you can see, it does an IPC over to the mDNSResponder process, at which point thread safety is assured." -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25924> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
A. Jesse Jiryu Davis added the comment: Related to #1288833, when FreeBSD 5.3's getaddrinfo was declared thread-safe. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25924> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
Changes by A. Jesse Jiryu Davis <je...@emptysquare.net>: Added file: http://bugs.python.org/file41597/d_mach ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25924> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
Changes by A. Jesse Jiryu Davis <je...@emptysquare.net>: Added file: http://bugs.python.org/file41596/h_resolv.c ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25924> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
A. Jesse Jiryu Davis added the comment: NetBSD has a concurrency test for getaddrinfo, so I tried it on Mac to see if getaddrinfo is thread-safe here, too. It appears that it is thread-safe. I copied NetBSD's getaddrinfo concurrency test "h_resolv.c" and the test's data file "d_mach" from src/tests/lib/libpthread in the NetBSD 7 source: http://cvsweb.netbsd.org/bsdweb.cgi/src/tests/lib/libpthread/ I've also attached these files to this ticket.* The test program h_resolv.c compiles fine on Mac OS X 10.10 with clang 7, and the test passes using the same parameters that the NetBSD test uses, resolving five host names on five threads: ./h_resolv -d -n 5 -h 5 d_mach There's even evidence that getaddrinfo is actually concurrent on my Mac: resolving 100 hostnames on 1 thread takes about 6 seconds, but using 100 threads take only 3 seconds. To test concurrency I ran this: sudo dscacheutil -flushcache sudo killall -HUP mDNSResponder time h_resolv -d -h 100 -n 1 d_mach sudo dscacheutil -flushcache sudo killall -HUP mDNSResponder time h_resolv -d -h 1 -n 100 d_mach Those sudo commands flush the Mac's DNS cache between runs. * I removed one unresolvable domain, "cnftp.bjpu.edu.cn", from the test file d_mach. That domain took 15 seconds to time out and made the rest of the timing irrelevant. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25924> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
A. Jesse Jiryu Davis added the comment: In Apple's Libinfo version 222.4.12 (corresponding to the last OS X 10.4 release), the man page says getaddrinfo isn't thread-safe: http://www.opensource.apple.com/source/Libinfo/Libinfo-222.4.12/lookup.subproj/getaddrinfo.3 And here's its source: http://www.opensource.apple.com/source/Libinfo/Libinfo-222.4.12/lookup.subproj/getaddrinfo.c Glancing at the source naïvely, I might see the data race: getaddrinfo calls gai_lookupd, which reads and writes the global static variable "gai_proc". I can't see what will go wrong as a result of the race, but it sure LOOKS bad. In the next release, version 278 (OS X 10.5.0), the thread-safety warning is gone from the man page: http://www.opensource.apple.com/source/Libinfo/Libinfo-278/lookup.subproj/getaddrinfo.3 And getaddrinfo is largely rewritten: http://www.opensource.apple.com/source/Libinfo/Libinfo-278/lookup.subproj/getaddrinfo.c It calls a new function, "ds_getaddrinfo". But ds_getaddrinfo still accesses the global static variable "gai_proc"; I wonder why this is considered thread-safe now? -- nosy: +emptysquare ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25924> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25920] PyOS_AfterFork should reset socketmodule's lock
New submission from A. Jesse Jiryu Davis: On some platforms there's an exclusive lock in socketmodule, used for getaddrinfo, gethostbyname, gethostbyaddr. A thread can hold this lock while another forks, leaving it locked forever in the child process. Calls to these functions in the child process will hang. (I wrote some more details here: https://emptysqua.re/blog/getaddrinfo-deadlock/ ) I propose that this is a bug, and that it can be fixed in PyOS_AfterFork, where a few similar locks are already reset. -- messages: 256815 nosy: emptysquare priority: normal severity: normal status: open title: PyOS_AfterFork should reset socketmodule's lock ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25920> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25274] sys.setrecursionlimit() must fail if the current recursion depth is higher than the new low-water mark
Changes by A. Jesse Jiryu Davis <je...@emptysquare.net>: -- nosy: +emptysquare ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25274> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25612] nested try..excepts don't work correctly for generators
Changes by A. Jesse Jiryu Davis <je...@emptysquare.net>: -- nosy: +emptysquare ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25612> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow
Changes by A. Jesse Jiryu Davis <je...@emptysquare.net>: -- nosy: +emptysquare ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25222> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24383] consider implementing __await__ on concurrent.futures.Future
Changes by A. Jesse Jiryu Davis je...@emptysquare.net: -- nosy: +emptysquare ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
Changes by A. Jesse Jiryu Davis je...@emptysquare.net: -- nosy: +emptysquare ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10544 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23915] traceback set with BaseException.with_traceback() overwritten on raise
A. Jesse Jiryu Davis added the comment: I've had a very hard time adding to the doc in a way that elucidates rather than further obfuscating; see if you like this patch. -- keywords: +patch nosy: +emptysquare Added file: http://bugs.python.org/file38916/issue23915.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23915 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22652] Add suggestion about keyword arguments to this error message: builtins.TypeError: my_func() takes 1 positional argument but 2 were given
A. Jesse Jiryu Davis added the comment: Attached patch adds and N keyword-only argument(s) to the TypeError message if a function takes keyword-only arguments and the wrong number of positional arguments is provided. -- keywords: +patch nosy: +emptysquare Added file: http://bugs.python.org/file38929/issue22652.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22652 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23464] Remove or deprecate JoinableQueue in asyncio docs
Changes by A. Jesse Jiryu Davis je...@emptysquare.net: -- keywords: +patch Added file: http://bugs.python.org/file38906/issue23464.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23464 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23464] Remove or deprecate JoinableQueue in asyncio docs
New submission from A. Jesse Jiryu Davis: asyncio.JoinableQueue was once a distinct subclass of asyncio.Queue, now it's just a deprecated alias. Once this is merged into CPython: https://code.google.com/p/tulip/issues/detail?id=220 ...then remove or deprecate JoinableQueue in asyncio-sync.rst -- components: asyncio messages: 235971 nosy: emptysquare, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: Remove or deprecate JoinableQueue in asyncio docs versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23464 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22898] segfault during shutdown attempting to log ResourceWarning
A. Jesse Jiryu Davis added the comment: With warn_4.patch applied I can no longer reproduce my original segfault, looks like the fix works. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22898 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22898] segfault during shutdown attempting to log ResourceWarning
New submission from A. Jesse Jiryu Davis: Running a unittest suite for Motor, my MongoDB driver which uses PyMongo, greenlet, and Tornado. The suite commonly segfaults during interpreter shutdown. I've reproduced this crash with Python 3.3.5, 3.4.1, and 3.4.2. Python 2.6 and 2.7 do *not* crash. The Python interpreters are all built like: ./configure --prefix=/mnt/jenkins/languages/python/rX.Y.Z --enable-shared make make install This is Amazon Linux AMI release 2014.09. The unittest suite's final output is: -- Ran 15 tests in 265.947s OK Segmentation fault (core dumped) Backtrace from a Python 3.4.2 coredump attached. -- components: Interpreter Core files: dump.txt messages: 231345 nosy: emptysquare priority: normal severity: normal status: open title: segfault during shutdown attempting to log ResourceWarning type: crash versions: Python 3.4 Added file: http://bugs.python.org/file37224/dump.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22898 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22898] segfault during shutdown attempting to log ResourceWarning
A. Jesse Jiryu Davis added the comment: The crash can ignore whether or not I specify -Wignore on the python command line. I was hoping to avoid the crash by short-circuiting the ResourceWarning code path, since the following line appears in the backtrace: #5 PyErr_WarnFormat (category=optimized out, stack_level=stack_level@entry=1, format=format@entry=0x7f5f1ca8b377 unclosed file %R) at Python/_warnings.c:813 But -Wignore has no effect. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22898 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21723] Float maxsize is treated as infinity in asyncio.Queue
Changes by A. Jesse Jiryu Davis je...@emptysquare.net: -- nosy: +emptysquare ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21723 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19071] Documentation on what self is for module-level functions is misleading/wrong.
Changes by A. Jesse Jiryu Davis je...@emptysquare.net: -- nosy: +emptysquare ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19071 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18418] Thread.isAlive() sometimes True after fork
A. Jesse Jiryu Davis added the comment: Thanks for accepting this patch! Antoine, I initially had trouble writing a test that reliably reproduced the bug, especially in Python 3.3. But I read other threading tests and got smarter. The final patch includes tests that are very reliable at revealing the bug in 2.7 and 3.3. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18418] Thread.isAlive() sometimes True after fork
A. Jesse Jiryu Davis added the comment: FYI I'm going on vacation again 8/20 through 8/25. I'll check in again as soon as I return to see if there's anything else I should do. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18418] Thread.isAlive() sometimes True after fork
A. Jesse Jiryu Davis added the comment: Bump. I think my most recent patch (August 4) addresses all of Charles-François's comments. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18418] Thread.isAlive() sometimes True after fork
A. Jesse Jiryu Davis added the comment: I'm back from a Zen retreat--no email!--will address your comments momentarily. On Fri, Aug 2, 2013 at 3:07 AM, Charles-François Natali rep...@bugs.python.org wrote: Charles-François Natali added the comment: I've posted another review (not sure you receive notifications). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18418 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18418] Thread.isAlive() sometimes True after fork
A. Jesse Jiryu Davis added the comment: New patch for 3.3 branch after Charles-François's critique: use _enumerate() where appropriate, and join the test thread before finishing the test. -- Added file: http://bugs.python.org/file31153/issue18418-3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18418] Thread.isAlive() sometimes True after fork
A. Jesse Jiryu Davis added the comment: By the way, I'm going on vacation through August 4. When I return I'll check if there's anything else I need to do to help resolve this. On Thursday, July 25, 2013, A. Jesse Jiryu Davis wrote: A. Jesse Jiryu Davis added the comment: (Sorry about the extraneous XML file from my IDE, I made a mistake and allowed the diff to include it.) -- ___ Python tracker rep...@bugs.python.org javascript:; http://bugs.python.org/issue18418 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18418] Thread.isAlive() sometimes True after fork
A. Jesse Jiryu Davis added the comment: Oh, no I didn't. I'm learning how this system works. I'll respond there soon. Thanks On Thursday, July 25, 2013, Charles-François Natali wrote: Charles-François Natali added the comment: Bump. Did you see my review at http://bugs.python.org/review/18418/#ps8668 ? -- ___ Python tracker rep...@bugs.python.org javascript:; http://bugs.python.org/issue18418 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18418] Thread.isAlive() sometimes True after fork
A. Jesse Jiryu Davis added the comment: New patch for 3.3 branch after Charles-François's critique: instead of changing startup sequence in Thread._bootstrap_inner, stop all threads in _limbo after a fork. -- Added file: http://bugs.python.org/file31035/issue18418-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18418] Thread.isAlive() sometimes True after fork
A. Jesse Jiryu Davis added the comment: (Sorry about the extraneous XML file from my IDE, I made a mistake and allowed the diff to include it.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18418] Thread.isAlive() sometimes True after fork
A. Jesse Jiryu Davis added the comment: Bump. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18418] Thread.isAlive() sometimes True after fork
A. Jesse Jiryu Davis added the comment: Charles-François, I agree that many guarantees are impossible to enforce in a multithreaded application that calls fork(). But the threading module does try to guarantee, after a fork, that isAlive() is False for all threads but one. I claim that it can more reliably provide this guarantee with my patch applied. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18418] Thread.isAlive() sometimes True after fork
A. Jesse Jiryu Davis added the comment: Patch #2: * Add comment before .set() as requested. * setcheckinterval(0) and try 20 times to repro the bug, inspired by test_enumerate_after_join. This reliably repros in 2.7.5. -- Added file: http://bugs.python.org/file30934/fix_is_alive_and_fork_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18418] Thread.isAlive() sometimes True after fork
Changes by A. Jesse Jiryu Davis je...@emptysquare.net: Added file: http://bugs.python.org/file30935/fix_is_alive_and_fork_python_33.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18418] Thread.isAlive() sometimes True after fork
New submission from A. Jesse Jiryu Davis: In threading.Thread.__bootstrap_inner(), the thread sets self.__started before adding itself to the _active collection. If a different thread forks between these two operations, we're left with a thread that believes it's alive although it isn't. _after_fork() doesn't call __stop() on this thread because the thread isn't in _active. In the attached patch, Thread adds itself to _active before setting self.__started. This way, if it's interrupted by a fork, it may end up stopped without being started, rather than the reverse. In this case isAlive() correctly returns False. One concern about the patch: my new test in test_threading.py only reveals the bug in Python 2.7.5 very occasionally. I don't know how to force the test to fail more frequently. Looking at the threading.py on the 3.3 branch, it appears to have the same bug, but I can't reproduce it there, only on the 2.7 branch. -- components: Library (Lib) files: fix_is_alive_and_fork.patch keywords: patch messages: 192780 nosy: emptysquare priority: normal severity: normal status: open title: Thread.isAlive() sometimes True after fork versions: Python 2.7 Added file: http://bugs.python.org/file30880/fix_is_alive_and_fork.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
