[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. >

[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.

[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 <http://bugs.python.org/issue18

[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 comm

[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'v

[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.

[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 <http://bugs.python.org/is

[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 <http://bugs.pyt

[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

[issue15851] Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default.

New submission from Eduardo A. Bustamante López: I found that http://en.wikipedia.org/robots.txt returns 403 if the provided user agent is in a specific blacklist. And since robotparser doesn't provide a mechanism to change the default user agent used by the opener, it becomes unusabl

[issue15851] Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default.

Changes by Eduardo A. Bustamante López : Added file: http://bugs.python.org/file27101/myrobotparser.py ___ Python tracker <http://bugs.python.org/issue15851> ___ ___ Pytho

[issue15851] Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default.

Eduardo A. Bustamante López added the comment: I guess a workaround is to do: robotparser.URLopener.version = 'MyVersion' -- ___ Python tracker <http://bugs.python.o

[issue15851] Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default.

Eduardo A. Bustamante López added the comment: I'm not sure what's the best approach here. 1. Avoid changes in the Lib, and document a work-around, which involves installing an opener with the specific User-agent. The draw-back is that it modifies the behaviour of urlopen() gl

[issue15851] Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default.

Eduardo A. Bustamante López added the comment: I forgot to mention that I ran a nc process in parallel, to see what data is being sent: ``nc -l -p ``. -- ___ Python tracker <http://bugs.python.org/issue15

[issue15851] Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default.

Eduardo A. Bustamante López added the comment: Hi Senthil, > I fail to see the bug in here. Robotparser module is for reading and > parsing the robot.txt file, the module responsible for fetching it > could urllib. You're right, but robotparser's read() does a call to urllib

[issue21723] Float maxsize is treated as infinity in asyncio.Queue

Changes by A. Jesse Jiryu Davis : -- nosy: +emptysquare ___ Python tracker <http://bugs.python.org/issue21723> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue19071] Documentation on what self is for module-level functions is misleading/wrong.

Changes by A. Jesse Jiryu Davis : -- nosy: +emptysquare ___ Python tracker <http://bugs.python.org/issue19071> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue16500] Add an 'atfork' module

Changes by A. Jesse Jiryu Davis : -- nosy: +emptysquare ___ Python tracker <http://bugs.python.org/issue16500> ___ ___ Python-bugs-list mailing list Unsubscribe:

[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 report

[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 <http://bugs.python.org/issue27

[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, '', (&

[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 someo

[issue27136] sock_connect fails for bluetooth (and probably others)

A. Jesse Jiryu Davis added the comment: Thank you Martin! -- ___ Python tracker <http://bugs.python.org/issue27136> ___ ___ Python-bugs-list mailing list Unsub

[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

[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

[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 <http://bugs.python.org/issue22

[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-syn

[issue24383] consider implementing __await__ on concurrent.futures.Future

Changes by A. Jesse Jiryu Davis : -- nosy: +emptysquare ___ Python tracker <http://bugs.python.org/issue24383> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow

Changes by A. Jesse Jiryu Davis : -- nosy: +emptysquare ___ Python tracker <http://bugs.python.org/issue25222> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue25612] nested try..excepts don't work correctly for generators

Changes by A. Jesse Jiryu Davis : -- nosy: +emptysquare ___ Python tracker <http://bugs.python.org/issue25612> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue25274] sys.setrecursionlimit() must fail if the current recursion depth is higher than the new low-water mark

Changes by A. Jesse Jiryu Davis : -- nosy: +emptysquare ___ Python tracker <http://bugs.python.org/issue25274> ___ ___ Python-bugs-list mailing list Unsubscribe:

[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

[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 it

[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 <http://bugs.python.org/is

[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe

Changes by A. Jesse Jiryu Davis : Added file: http://bugs.python.org/file41596/h_resolv.c ___ Python tracker <http://bugs.python.org/issue25924> ___ ___ Python-bugs-list m

[issue25924] investigate if getaddrinfo(3) on OSX is thread-safe

Changes by A. Jesse Jiryu Davis : Added file: http://bugs.python.org/file41597/d_mach ___ Python tracker <http://bugs.python.org/issue25924> ___ ___ Python-bugs-list m

[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 fi

[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, hairdryer

[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

[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 <http://bugs.python.org/issue25924> ___ ___ Python-bug

[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-t

[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 do

[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 wo

[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 <http://bugs.pyt

[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

[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-netbs

[issue26406] getaddrinfo is thread-safe on NetBSD and OpenBSD

A. Jesse Jiryu Davis added the comment: Thank you! -- ___ Python tracker <http://bugs.python.org/issue26406> ___ ___ Python-bugs-list mailing list Unsubscribe:

[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 <http://bugs.python.org/issue25924> ___ ___ Pytho

[issue6721] Locks in the standard library should be sanitized on fork

Changes by A. Jesse Jiryu Davis : -- nosy: +emptysquare ___ Python tracker <http://bugs.python.org/issue6721> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue23464] Remove or deprecate JoinableQueue in asyncio docs

Changes by A. Jesse Jiryu Davis : -- keywords: +patch Added file: http://bugs.python.org/file38906/issue23464.diff ___ Python tracker <http://bugs.python.org/issue23

[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.

[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

[issue10544] yield expression inside generator expression does nothing

Changes by A. Jesse Jiryu Davis : -- nosy: +emptysquare ___ Python tracker <http://bugs.python.org/issue10544> ___ ___ Python-bugs-list mailing list Unsubscribe:

[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

[issue1564547] Py_signal_pipe

Gustavo J. A. M. Carneiro added the comment: "My understanding is that there are some things that the current patch does not address." Well, I don't know what those things are, so it's hard for me to address them. :-) _ Tracker <[

[issue1564547] Py_signal_pipe

Gustavo J. A. M. Carneiro added the comment: Minimal patch that just adds the pipe but does not attempt to fix anything else. Added file: http://bugs.python.org/file8898/python-signals-minimal.diff _ Tracker <[EMAIL PROTECTED]> <http://bugs.p

[issue1564547] Py_signal_pipe

Gustavo J. A. M. Carneiro added the comment: > The minimal patch doesn't initialize dummy_char or dummy_c. It's harmless here, but please fix it. ;) The variable is called 'dummy' for a reason. The value written or read is irrevelant... __

[issue1583] Patch for signal.set_wakeup_fd

Gustavo J. A. M. Carneiro added the comment: The patch looks great. But I was wondering if there is any chance to export a C API in addition to the Python one? That is because PyGTK is mostly C, the code that needs this is C, it would be easier to call a C API. -- nosy: +gustavo

[issue1583] Patch for signal.set_wakeup_fd

Changes by Gustavo J. A. M. Carneiro: __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1583> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue1772673] Replacing char* with const char*

Gustavo J. A. M. Carneiro added the comment: I was about to submit the very same patch :-) I missed PyErr_NewException, but you missed the PyMapping_* methods ;) Please look into this matter. GCC 4.2 has arrived and it has a new warning. The code: char* kwlist[] = { "target",

[issue1715] Make pydoc list submodules

New submission from Gustavo J. A. M. Carneiro: Often python extension modules define submodules like this: static PyObject * initfoo_xpto(void) { PyObject *m; m = Py_InitModule3("foo.xpto", foo_xpto_functions, NULL); [...] return m; } PyMODINIT_FUNC initfoo(void) {

[issue2663] shutil.copytree glob-style filtering [patch]

Changes by Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]>: -- nosy: +gustavo __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2663> __ ___ Python-bugs

[issue975646] tp_(get|set)attro? inheritance bug

Gustavo J. A. M. Carneiro added the comment: If this problem does not apply to Python 3.x, by all means go ahead and close it. It probably is a bug, but probably not worth fixing; workaround is simple enough, and affected extensions have already adapted to it

[issue41111] Convert a few stdlib extensions to the limited C API

Change by Gustavo J. A. M. Carneiro : -- nosy: +gustavo ___ Python tracker <https://bugs.python.org/issue4> ___ ___ Python-bugs-list mailing list Unsub

[issue32528] Change base class for futures.CancelledError

Gustavo J. A. M. Carneiro added the comment: What a shame, I've seen this error many times as well. Surely making it BaseException will not break that much code?... -- nosy: +gustavo ___ Python tracker <https://bugs.python.org/is

[issue20519] uuid.uuid4().hex generates garbage when ctypes available

New submission from Gustavo J. A. M. Carneiro: If you try the attached program, you will find that for every iteration the uuid.uuid4() call generates objects that contain reference cycles and need the help of the garbage collector. This is not nice. If I make the ctypes module not able to

[issue20519] uuid.uuid4().hex generates garbage when ctypes available

Gustavo J. A. M. Carneiro added the comment: Well, this isn't a big problem, but I have an application that needs to run with the GC disabled, since it causes pauses of a couple of seconds each time a full collection runs (we have a few million objects allocated). I will run the GC only

[issue20519] uuid.uuid4().hex generates garbage when ctypes available

Gustavo J. A. M. Carneiro added the comment: I have narrowed it down to one line of code: ctypes.create_string_buffer(16) That is enough to create 7 objects that have reference cycles. [, {'__module__': 'ctypes', '__doc__': None, '__weakref__': , '

[issue20519] ctypes.create_string_buffer creates reference cycles

Gustavo J. A. M. Carneiro added the comment: Regardless, if you don't mind, take this patch for Python 3.5 to avoid ctypes, at least in the Linux case (I don't have Windows to test). Creating a proper extension module is safer and really not that hard... -- keywords: +p

[issue23812] asyncio.Queue.put_nowait(), followed get() task cancellation leads to item being lost

Gustavo J. A. M. Carneiro added the comment: Don't know if it helps, but I made a github pull request for this: https://github.com/python/asyncio/pull/256 -- ___ Python tracker <http://bugs.python.org/is

[issue23812] asyncio.Queue.put_nowait(), followed get() task cancellation leads to item being lost

Gustavo J. A. M. Carneiro added the comment: I don't think the order for multiple concurrent getters matters that much. With analogy with the threading case, if multiple threads are blocked get()ing an item from the same queue, I would not presume to expect anything about the ordering

[issue23812] asyncio.Queue.put_nowait(), followed get() task cancellation leads to item being lost

Gustavo J. A. M. Carneiro added the comment: Sure, just give me a couple of days. -- ___ Python tracker <http://bugs.python.org/issue23812> ___ ___ Python-bug

[issue23812] asyncio.Queue.put_nowait(), followed get() task cancellation leads to item being lost

Gustavo J. A. M. Carneiro added the comment: I was wrong, there still needs to be some cleanup in cancellation, even with the new approach. But it does solve the out-of-order problem. I don't know if it should be applied to rc1. I wish I had more time to test. Up to you

[issue23812] asyncio.Queue.put_nowait(), followed get() task cancellation leads to item being lost

Gustavo J. A. M. Carneiro added the comment: I am not using hg anymore, since asyncio migrated to git. Here's a github PR, does that help? https://github.com/python/asyncio/pull/260 -- ___ Python tracker <http://bugs.python.org/is

[issue20519] Replace uuid ctypes usage with an extension module.

Gustavo J. A. M. Carneiro added the comment: This patch fixes the Mac OS X issue @haypo pointed out. -- Added file: http://bugs.python.org/file40865/issue20519_10941v2.diff ___ Python tracker <http://bugs.python.org/issue20

[issue20519] Replace uuid ctypes usage with an extension module.

Gustavo J. A. M. Carneiro added the comment: One issue of note is regarding generate_time(). Originally I found ctypes bindings for this function, so I wrapped it as well in the extension module. However, it doesn't appear to be

[issue20519] Replace uuid ctypes usage with an extension module.

Gustavo J. A. M. Carneiro added the comment: New patch that: 1. adds assert(sizeof(uuid_t) == 16); to the extension module; 2. fixes the code path when ctypes has to be used instead of the extension module (needed a bit more refactoring, apologies if it makes the diff harder to read); 3

[issue23812] asyncio.Queue.put_nowait(), followed get() task cancellation leads to item being lost

New submission from Gustavo J. A. M. Carneiro: I have a pattern where I read from a queue with a timeout, generally like this: while True: reader = asyncio.async(wait_for(queue.get(), 0.1)) try: item = (yield from reader) except asyncio.TimeoutError: reader.cancel() continue

[issue23812] asyncio.Queue.put_nowait(), followed get() task cancellation leads to item being lost

Changes by Gustavo J. A. M. Carneiro : Added file: http://bugs.python.org/file38741/Issue23812.diff ___ Python tracker <http://bugs.python.org/issue23812> ___ ___ Pytho

[issue23812] asyncio.Queue.put_nowait(), followed get() task cancellation leads to item being lost

Gustavo J. A. M. Carneiro added the comment: I created a codereview issue: https://codereview.appspot.com/222930043 -- ___ Python tracker <http://bugs.python.org/issue23

[issue23812] asyncio.Queue.put_nowait(), followed get() task cancellation leads to item being lost

Gustavo J. A. M. Carneiro added the comment: > - Are there other places where a cancellation can have a similar effect? > Maybe the same logic in put()? Hm.. I didn't look, but yes, it does look like it might be affected by the same issue. I'll try to create a test for

[issue23812] asyncio.Queue.put_nowait(), followed get() task cancellation leads to item being lost

Gustavo J. A. M. Carneiro added the comment: So I uploaded a new patch version fixing a similar problem in put(). -- ___ Python tracker <http://bugs.python.org/issue23

<    21   22   23   24   25   26