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/issue22
Change by A. Jesse Jiryu Davis :
--
nosy: -emptysquare
___
Python tracker
<https://bugs.python.org/issue6721>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 <
A. Jesse Jiryu Davis added the comment:
Thank you Martin!
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27136>
___
___
Pyth
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
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
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/i
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.
Changes by A. Jesse Jiryu Davis <je...@emptysquare.net>:
--
nosy: +emptysquare
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by A. Jesse Jiryu Davis <je...@emptysquare.net>:
--
nosy: +emptysquare
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pytho
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/i
A. Jesse Jiryu Davis added the comment:
Thank you!
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26406>
___
___
Python-bugs-
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-ope
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
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>
<htt
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 i
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
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
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/i
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
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, et
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/i
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
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
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
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
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
Changes by A. Jesse Jiryu Davis <je...@emptysquare.net>:
--
nosy: +emptysquare
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by A. Jesse Jiryu Davis <je...@emptysquare.net>:
--
nosy: +emptysquare
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by A. Jesse Jiryu Davis <je...@emptysquare.net>:
--
nosy: +emptysquare
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by A. Jesse Jiryu Davis je...@emptysquare.net:
--
nosy: +emptysquare
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python
Changes by A. Jesse Jiryu Davis je...@emptysquare.net:
--
nosy: +emptysquare
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10544
___
___
Python
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
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
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
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
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
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
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
Changes by A. Jesse Jiryu Davis je...@emptysquare.net:
--
nosy: +emptysquare
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21723
___
___
Python
Changes by A. Jesse Jiryu Davis je...@emptysquare.net:
--
nosy: +emptysquare
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19071
___
___
Python
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
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
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
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
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
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
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
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
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
A. Jesse Jiryu Davis added the comment:
Bump.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18418
___
___
Python-bugs-list mailing list
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
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
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
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
55 matches
Mail list logo
