[issue24596] Script globals in a GC cycle not finalized when exiting with SystemExit

Antoine Pitrou added the comment: New changeset 20ae4c60258479a0732d12af292f422679444e2c by Antoine Pitrou (Miss Islington (bot)) in branch '3.7': bpo-24596: Decref module in PyRun_SimpleFileExFlags() on SystemExit (GH-7918) (GH-8070) https://github.com/python/cpython/commit

[issue24596] Script globals in a GC cycle not finalized when exiting with SystemExit

Antoine Pitrou added the comment: New changeset d8cba5d16f1333fd625726fc72e66afbd45b8d00 by Antoine Pitrou (Zackery Spytz) in branch 'master': bpo-24596: Decref module in PyRun_SimpleFileExFlags() on SystemExit (GH-7918) https://github.com/python/cpython/commit

[issue34034] Python 3.7.0 multiprocessing forkserver ForkingPickler behaviour change

Antoine Pitrou added the comment: It could be many different things. The bottom line here, though, is that the Process class is not designed to be picklable (how would it work?), which is probably why you're seeing this. -- nosy: +pitrou

[issue34009] Document Travis CI / Ubuntu 14.04 OpenSSL compatibility issues

Antoine Pitrou added the comment: Why should we mention Travis-CI at all? It's Travis-CI's job to document the binaries and runtimes they provide on each of their build environments. -- nosy: +pitrou ___ Python tracker <https://bugs.python.

[issue33939] Provide a robust O(1) mechanism to check for infinite iterators

Antoine Pitrou added the comment: I think being able to handle Ctrl-C would be the right solution here. Not handling Ctrl-C is a problem also for very long but non-infinite iterators. -- ___ Python tracker <https://bugs.python.org/issue33

[issue33939] Provide a robust O(1) mechanism to check for infinite iterators

Antoine Pitrou added the comment: Downside of __infinite_iterator__: another additional attribute to look up, and its functionality overlaps with __length_hint__. I'd rather have a special return value for __length_hint__ (e.g. -1, -2, whatever). -- nosy: +pitrou

[issue33944] Deprecate and remove pth files

Antoine Pitrou added the comment: I would also add that editable installs should not break in the process. They are important. -- nosy: +pitrou ___ Python tracker <https://bugs.python.org/issue33

[issue33613] test_multiprocessing_fork: test_semaphore_tracker_sigint() fails with -W error

Antoine Pitrou added the comment: Is it possible to notify the ping / noop reply on stderr instead of introducing a new pipe? -- ___ Python tracker <https://bugs.python.org/issue33

[issue33945] concurrent.futures ProcessPoolExecutor submit() blocks on results being written

Antoine Pitrou added the comment: I'm not sure what happens exactly in your workload, but waiting 20 seconds when posting some data on an unbounded queue sounds enormous. -- nosy: +tomMoral ___ Python tracker <https://bugs.python.org/issue33

[issue33613] test_multiprocessing_fork: test_semaphore_tracker_sigint() fails with -W error

Antoine Pitrou added the comment: We can easily add a 'NOOP' command to the semaphore tracker if it helps solve that issue. -- ___ Python tracker <https://bugs.python.org/issue33

[issue33716] test_concurrent_futures.test_crash() failed on x86 Windows7 3.7

Antoine Pitrou added the comment: I don't remember :-/ It's probably ok to increase the timeout, though. -- ___ Python tracker <https://bugs.python.org/issue33

[issue33301] Add __contains__ to pathlib

Antoine Pitrou added the comment: Not a good idea IMHO. Why would containment mean the existence of a file in a directory? It could just as well mean that a certain path component is part of the path. Also I don't understand what would e.g. `Path('/usr/bar') in Path('/etc/foo')` mean

[issue32388] Remove cross-version binary compatibility

Antoine Pitrou added the comment: > Does it mean that Python 3.8 wil crash on loading C extensions compiled on > Python older than this version? What makes you think that it would be otherwise be able to load and execute such C extensions without any bugs? There is no ABI except the

[issue33895] LoadLibraryExW called with GIL held can cause deadlock

Antoine Pitrou added the comment: Do you want to submit a PR for this? You can take a look at our developer's guide if you're new to contributing to Python: https://devguide.python.org/ -- nosy: +pitrou stage: -> needs patch type: -> behavior versions: -Python 2.7, Pyth

[issue33884] [multiprocessing] Multiprocessing in spawn mode doesn't work when the target is a method in a unittest.TestCase subclass, when run either with unittest or with pytest

Antoine Pitrou added the comment: While this is limitation of the spawn and forkserver modes, I don't see how this is a bug. Also, as you point out, making the method a classmethod or staticmethod works around the limitation. -- resolution: -> not a bug stage: -> resolved

[issue33858] A typo in multiprocessing documentation

Antoine Pitrou added the comment: Ok, I've backported to 3.6 in https://github.com/python/cpython/pull/7721 -- components: +Library (Lib) resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior ___ Python tra

[issue33841] lock not released in threading.Condition

Antoine Pitrou added the comment: The `waiter` lock is always removed from `self._waiters` at the end of wait() (either by notify() or by wait() itself), so there's no point in releasing it a second time before destruction. I'm closing this as it's not a bug. -- nosy: +pitrou

[issue30747] _Py_atomic_* not actually atomic on Windows with MSVC

Antoine Pitrou added the comment: I would be ok with reverting to the non-HLE variants. Does anyone want to test the performance implications on TSX-enabled hardware? -- ___ Python tracker <https://bugs.python.org/issue30

[issue9141] Allow objects to decide if they can be collected by GC

Antoine Pitrou added the comment: It's hard to say as I never fully understood the underlying intent. Perhaps Kristján or some other developer who better understood than me can chime in. -- ___ Python tracker <https://bugs.python.org/issue9

[issue30654] signal module always overwrites SIGINT on interpreter shutdown

Antoine Pitrou added the comment: So this is in 2.7 finally. Closing again. -- stage: patch review -> resolved status: open -> closed versions: +Python 2.7 ___ Python tracker <https://bugs.python.org/i

[issue30654] signal module always overwrites SIGINT on interpreter shutdown

Antoine Pitrou added the comment: New changeset ded666ff0ce44785a495ff89b676ca68e4cc08e8 by Antoine Pitrou in branch '2.7': [2.7] bpo-30654: Do not reset SIGINT handler to SIG_DFL in finisignal (GH-7146) (GH-7347) https://github.com/python/cpython/commit

[issue33738] PyIndex_Check conflicts with PEP 384

Antoine Pitrou added the comment: > related personal note - does someone know what happened to Martin? I don't think anything bad happened. He still seems to be teaching: http://www.beuth-hochschule.de/people/detail/1398/ -- nosy: +pit

[issue30654] signal module always overwrites SIGINT on interpreter shutdown

Change by Antoine Pitrou : -- pull_requests: +6973 stage: resolved -> patch review ___ Python tracker <https://bugs.python.org/issue30654> ___ ___ Python-

[issue30654] signal module always overwrites SIGINT on interpreter shutdown

Antoine Pitrou added the comment: Reopening for the 2.7 backport discussion. -- status: closed -> open ___ Python tracker <https://bugs.python.org/issu

[issue30416] constant folding opens compiler to quadratic time hashing

Antoine Pitrou added the comment: I vote for "won't fix". 2.7 has lived long enough with this issue, AFAIU. And it won't be triggered by regular code. -- ___ Python tracker <https://bugs.python.o

[issue33739] pathlib: Allow ellipsis to appear after "/" to navigate to parent path

Antoine Pitrou added the comment: I've just tried, "..." doesn't seem to mean anything on the Windows CLI. But I agree with the reservation that having "..." mean something different than ".." is a recipe for confusion.

[issue30654] signal module always overwrites SIGINT on interpreter shutdown

Antoine Pitrou added the comment: Short of any bug in the patch, yes, it's stricly an improvement. -- ___ Python tracker <https://bugs.python.org/issue30

[issue33650] asyncio: Prohibit adding a signal handler for SIGCHLD

Antoine Pitrou added the comment: Some people may have reasons to do that (for example: they write their own subprocess implementation). I suggest emitting a warning rather than forbidding it. -- nosy: +pitrou ___ Python tracker <ht

[issue33650] asyncio: Prohibit adding a signal handler for SIGCHLD

Change by Antoine Pitrou : -- title: Prohibit adding a signal handler for SIGCHLD -> asyncio: Prohibit adding a signal handler for SIGCHLD ___ Python tracker <https://bugs.python.org/issu

[issue30654] signal module always overwrites SIGINT on interpreter shutdown

Antoine Pitrou added the comment: I'm nosy'ing Benjamin, the 2.7 release manager, in case he wants to comment on desirability of this bugfix in Python 2.7. -- nosy: +benjamin.peterson ___ Python tracker <https://bugs.python.org/issue30

[issue30654] signal module always overwrites SIGINT on interpreter shutdown

Change by Antoine Pitrou : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue30654] signal module always overwrites SIGINT on interpreter shutdown

Antoine Pitrou added the comment: New changeset 1d5198fd41ad9185e9e6b3aa595769c3693d57be by Antoine Pitrou (Miss Islington (bot)) in branch '3.6': bpo-30654: Do not reset SIGINT handler to SIG_DFL in finisignal (GH-7146) (GH-7307) https://github.com/python/cpython/commit

[issue33725] High Sierra hang when using multi-processing

Antoine Pitrou added the comment: I understand that Apple, with their limited resources, cannot spend expensive engineer manpower on improving POSIX support in macOS . In any case, I'm unsure this bug can be fixed at the Python level. If macOS APIs don't like fork(), they don't like fork

[issue30654] signal module always overwrites SIGINT on interpreter shutdown

Antoine Pitrou added the comment: New changeset 623b439abebc913bc416d92f38fe371e84b0276b by Antoine Pitrou (Miss Islington (bot)) in branch '3.7': bpo-30654: Do not reset SIGINT handler to SIG_DFL in finisignal (GH-7146) (GH-7306) https://github.com/python/cpython/commit

[issue30654] signal module always overwrites SIGINT on interpreter shutdown

Antoine Pitrou added the comment: Ok, I think it go into 3.7.0 after all. 3.7.1 wouldn't get more testing before it's released anyway. -- ___ Python tracker <https://bugs.python.org/issue30

[issue30654] signal module always overwrites SIGINT on interpreter shutdown

Antoine Pitrou added the comment: > For 3.7, we are very close to the final release. It doesn't give much time to > users to test the new behavior That's a fair point. What's the procedure here? If I backport the fix to the 3.7 branch, will it go straight into the 3.7.0 r

[issue30654] signal module always overwrites SIGINT on interpreter shutdown

Antoine Pitrou added the comment: > So if an application has its own signal handler, Python replaces it... You have it backwards. Please read the bug report. -- ___ Python tracker <https://bugs.python.org/issu

[issue30654] signal module always overwrites SIGINT on interpreter shutdown

Antoine Pitrou added the comment: I'd rather not backport this to 2.7 as it's quite late in the maintenance cycle and I'd like to avoid any regressions there. -- ___ Python tracker <https://bugs.python.org/issue30

[issue30654] signal module always overwrites SIGINT on interpreter shutdown

Change by Antoine Pitrou : -- versions: +Python 3.8 -Python 2.7, Python 3.5 ___ Python tracker <https://bugs.python.org/issue30654> ___ ___ Python-bugs-list m

[issue30654] signal module always overwrites SIGINT on interpreter shutdown

Antoine Pitrou added the comment: New changeset e905c84494526363086f66a979e317e155bf9536 by Antoine Pitrou (pkerling) in branch 'master': bpo-30654: Do not reset SIGINT handler to SIG_DFL in finisignal (GH-7146) https://github.com/python/cpython/commit

[issue33597] Compact PyGC_Head

Antoine Pitrou added the comment: Here is a micro-benchmark of GC overhead: * before: $ ./python -m timeit -s "import gc, doctest, ftplib, asyncio, email, http.client, pydoc, pdb, fractions, decimal, difflib, textwrap, statistics, shutil, shelve, lzma, concurrent.futures, telnetlib,

[issue33713] memoryview can set an exception in tp_clear

Antoine Pitrou added the comment: Yes, tp_clear can be called with refcount > 0. It's exactly why it's separate from tp_dealloc, actually :-) -- ___ Python tracker <https://bugs.python.org/issu

[issue33713] memoryview can set an exception in tp_clear

Antoine Pitrou added the comment: Serhiy is right about the theoretical concern here. However, it's probably quite difficult to find a concrete situation where this occurs, because we're talking about mbuf_clear and the managerbuffer object can't really get involved in a reference cycle

[issue33532] test_multiprocessing_forkserver: TestIgnoreEINTR.test_ignore() fails on Travis CI

Antoine Pitrou added the comment: Did your PR fix the issue? -- ___ Python tracker <https://bugs.python.org/issue33532> ___ ___ Python-bugs-list mailin

[issue33607] [subinterpreters] Explicitly track object ownership (and allocator).

Antoine Pitrou added the comment: I agree with Victor, we shouldn't add PyObject fields that only have use in certain (minority) situations. The idea of tracking per arena will be non-trivial to implement, as only small objects (smaller than 512 bytes) use our own allocator; larger objects

[issue33597] Compact PyGC_Head

Antoine Pitrou added the comment: As I said, the code just defers to "perf". And you should have tested that :-) I'm not really interested in checking it. All I know is that the very old code (inherited from Unladen Swallow) did memory tracking correctly. And I have

[issue33597] Compact PyGC_Head

Antoine Pitrou added the comment: > I'm not sure that the code tracking the memory usage in performance works Why wouldn't it? It certainly gives believable numbers (see above). And it seems to defer to your own "perf" tool anyway. > perf has two options: --track-memory a

[issue33597] Compact PyGC_Head

Antoine Pitrou added the comment: Ok, I ran a subset of the benchmarks to record their memory footprint and got these results: master-mem.perf === Performance version: 0.6.2 Python version: 3.8.0a0 (64-bit) revision 73cbe7a Report on Linux-4.15.0-22-generic-x86_64-with-glibc2.9

[issue33597] Compact PyGC_Head

Antoine Pitrou added the comment: > Are you sure that all memory allocators align at least on 8 bytes (to give up > 3 unused bits)? If they don't then a simple double array will end up unaligned. It's not impossible but extremely un

[issue33632] undefined behaviour: signed integer overflow in threadmodule.c

New submission from Antoine Pitrou <pit...@free.fr>: Modules/_threadmodule.c:52:47: runtime error: signed integer overflow: 2387971499048 + 92233720360 cannot be represented in type 'long' -- components: Library (Lib) messages: 317545 nosy: pitrou priority: normal se

[issue33627] test-complex of test_numeric_tower.test_complex() crashes intermittently on Ubuntu buildbots

Antoine Pitrou <pit...@free.fr> added the comment: Those two builders are using Ubuntu 14.04 specifically (with different CPU architectures). I couldn't reproduce on my 16.04 machine. Perhaps something odd on 14.04? Do we have builds with Adress Sanatizer or Undefined Behavior San

[issue33621] repr(threading._DummyThread) always fails.

Antoine Pitrou <pit...@free.fr> added the comment: Can you post the actual exception you are getting? Here I have: >>> import threading >>> repr(threading._DummyThread()) '<_DummyThread(Dummy-1, started daemon 140345620215552)&

[issue33622] Fix errors handling in the garbage collector

Change by Antoine Pitrou <pit...@free.fr>: -- priority: normal -> low ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33622> ___ __

[issue32458] test_asyncio: test_start_tls_server_1() fails randomly

Change by Antoine Pitrou <pit...@free.fr>: -- nosy: -pitrou ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32458> ___ __

[issue33565] strange tracemalloc results

Change by Antoine Pitrou <pit...@free.fr>: -- nosy: -pitrou ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33565> ___ __

[issue31463] test_multiprocessing_fork hangs test_subprocess

Antoine Pitrou <pit...@free.fr> added the comment: Let's take another look at the issue: why does test_subprocess need to know about all child processes, rather than those that were launched during test_subprocess? -- ___ Python tracke

[issue33612] Assertion failure in PyThreadState_Clear

Antoine Pitrou <pit...@free.fr> added the comment: Le 23/05/2018 à 13:57, STINNER Victor a écrit : > > I agree that in a perfect world, Python should cleanup everything properly, > but in the current world, daemon threads and fork are a mess full of corner > cases like this

[issue33612] Assertion failure in PyThreadState_Clear

Antoine Pitrou <pit...@free.fr> added the comment: Yes, simply removing the assertion feels more like a copout than an actual fix. (perhaps it *is* the right fix to the issue, but it would be nice to find out why :-)) -- ___ Python tracke

[issue33612] Assertion failure in PyThreadState_Clear

Change by Antoine Pitrou <pit...@free.fr>: -- priority: normal -> critical ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33612> ___ _

[issue33603] Subprocess Thread handles grow with each call and aren't released until script ends

Change by Antoine Pitrou <pit...@free.fr>: -- nosy: +giampaolo.rodola, gregory.p.smith ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue33597] Compact PyGC_Head

Antoine Pitrou <pit...@free.fr> added the comment: Le 22/05/2018 à 17:31, INADA Naoki a écrit : > > INADA Naoki <songofaca...@gmail.com> added the comment: > > $ ./python-gc -c 'import asyncio,sys; sys._debugmallocstats()' Thanks. You can also collect peak memory st

[issue33597] Compact PyGC_Head

Antoine Pitrou <pit...@free.fr> added the comment: Interesting. Do you have any comparisons on memory footprint too? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue33589] Remove dummy member in GCHead

Antoine Pitrou <pit...@free.fr> added the comment: I'm fine with an anonymous struct. Is it standard C these days? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue33589] Remove dummy member in GCHead

Antoine Pitrou <pit...@free.fr> added the comment: Short of adding a `tp_alignment`, though, I think we should not make things harder for the common cases. This means we should probably keep the "double" member to ensure that extension types that have a "double" fie

[issue33589] Remove dummy member in GCHead

Antoine Pitrou <pit...@free.fr> added the comment: >From the linked changeset message: > unless anyone knows of a platform where ssize_t is 4 bytes? That's most 32-bit platforms, right? Basically, size_t and ssize_t are pointer-sized except on some rare architectures. > A m

[issue33583] PyObject_GC_Resize() doesn't relink GCHead

Antoine Pitrou <pit...@free.fr> added the comment: I think we can simply document it. I don't think anyone has silently buggy code, since it would probably cause a crash as soon as the chain of objects is walked. If we want to fix PyObject_GC_Resize(), we should check that benc

[issue33521] Add 1.32x faster C implementation of asyncio.isfuture().

Antoine Pitrou <pit...@free.fr> added the comment: Then it would be nice to post benchmarks using asyncio.gather() (on something not too trivial perhaps). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue33521] Add 1.32x faster C implementation of asyncio.isfuture().

Antoine Pitrou <pit...@free.fr> added the comment: What is the impact on a regular application? The fact that a micro-benchmark becomes X% faster isn't very interesting itself, especially as the original function, at less than 1µs per call, is already very fast. -- nosy: +

[issue19251] bitwise ops for bytes of equal length

Antoine Pitrou <pit...@free.fr> added the comment: Please, let's have this API discussion outside of the bug tracker. This deserves a PEP. Also because I have an alternative API to suggest :-) -- ___ Python tracker <rep...@bugs.python.or

[issue33565] strange tracemalloc results

Antoine Pitrou <pit...@free.fr> added the comment: Can you post a reproducer that doesn't involve S3? -- nosy: +pitrou ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue19251] bitwise ops for bytes of equal length

Antoine Pitrou <pit...@free.fr> added the comment: Le 17/05/2018 à 18:20, Nick Coghlan a écrit : > > The question is whether we might be able to avoid some > bytes->Python-objects->bytes cycles if there were a few more > contiguous-binary-data-centric operations on

[issue21145] Add the @cached_property decorator

Antoine Pitrou <pit...@free.fr> added the comment: I agree this would be a useful addition to the stdlib. The code might seem reasonably short, but implementing new descriptors is an advanced topic (I'd rather avoid it myself). -- ___

[issue33451] Start pyc file lock the file

Change by Antoine Pitrou <pit...@free.fr>: -- nosy: +brett.cannon, eric.snow, ncoghlan, paul.moore, steve.dower, tim.golden, zach.ware ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue33526] hashlib leak on import

Change by Antoine Pitrou <pit...@free.fr>: -- nosy: +christian.heimes, gregory.p.smith ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue33522] Enable CI builds on Visual Studio Team Services

Antoine Pitrou <pit...@free.fr> added the comment: Can you explain what Visual Studio Team Services is? -- nosy: +pitrou ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue22069] TextIOWrapper(newline="\n", line_buffering=True) mistakenly treat \r as a newline

Change by Antoine Pitrou <pit...@free.fr>: -- nosy: -pitrou ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue22069> ___ __

[issue28055] pyhash's siphash24 assumes alignment of the data pointer

Antoine Pitrou <pit...@free.fr> added the comment: Indeed the memcpy() approach is the common idiom in such situations, and sounds like the right thing. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue4934] tp_del and tp_version_tag undocumented

Antoine Pitrou <pit...@free.fr> added the comment: Both tp_del and tp_version_tag are for internal use. Besides, tp_del is obsolete as I mentioned above. So I'm going to close the issue. -- resolution: -> not a bug stage: -> resolved status: op

[issue4934] tp_del and tp_version_tag undocumented

Antoine Pitrou <pit...@free.fr> added the comment: The reason tp_del has remained undocumented is that it's now obsolete. You should use tp_finalize instead: https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_finalize tp_finalize is roughly the C equivalent of __del__ (

[issue33444] Memory leak/high usage on copy in different thread

Change by Antoine Pitrou <pit...@free.fr>: -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bu

[issue33444] Memory leak/high usage on copy in different thread

Antoine Pitrou <pit...@free.fr> added the comment: Yes, this looks surprising, but there is no memory leak here, just memory fragmentation in the glibc allocator. This is the program I used to diagnose it: https://gist.github.com/pitrou/6c5310d4c721436165666044e3c31158 At the end the p

[issue33439] python-config.py should be part of the stdlib

New submission from Antoine Pitrou <pit...@free.fr>: Rather than (or in addition to) being a standalone script, python-config should be invokable as a stdlib module, e.g. "python -m sysconfig.config". This would prevent the risk of invoking the wrong script on PATH. -

[issue33438] pkg-config file misses flags for static linking

Antoine Pitrou <pit...@free.fr> added the comment: Note that both implementations of python-config give the right information: $ ./python python-config.py --libs -lpython3.7m -lpthread -ldl -lutil -lm $ sh python-config --libs -lpython3.7m -lpthread -ldl -lut

[issue33438] pkg-config file misses flags for static linking

Antoine Pitrou <pit...@free.fr> added the comment: (correction: in the first message, I meant "on Linux" not "on Windows". Of course :-)) -- ___ Python tracker <rep...@bugs.python.org> <

[issue33438] pkg-config file misses flags for static linking

Antoine Pitrou <pit...@free.fr> added the comment: $ PKG_CONFIG_PATH=`pwd`/Misc pkg-config --static python $ PKG_CONFIG_PATH=`pwd`/Misc pkg-config --libs python -L/home/antoine/cpython/37/usr/lib -lpython3.7m $ PKG_CONFIG_PATH=`pwd`/Misc pkg-config --libs-only-l python -lpyth

[issue33438] pkg-config file misses flags for static linking

New submission from Antoine Pitrou <pit...@free.fr>: Our pkg-config misses flags for static linking with libpythonXX.a, such as "-lpthread -lutil -lrt" on Windows. For dynamic linking, this is not a problem since libpythonXX.so links explicitly against those

[issue33332] Expose valid signal set (sigfillset()): add signal.valid_signals()

Antoine Pitrou <pit...@free.fr> added the comment: Yes, but we're not losing anything by being overly cautious. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue33332] Expose valid signal set (sigfillset()): add signal.valid_signals()

Antoine Pitrou <pit...@free.fr> added the comment: This is expected, see issue33329. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue33332] Expose valid signal set (sigfillset()): add signal.valid_signals()

Change by Antoine Pitrou <pit...@free.fr>: -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bu

[issue33332] Expose valid signal set (sigfillset()): add signal.valid_signals()

Antoine Pitrou <pit...@free.fr> added the comment: New changeset 9d3627e311211a1b4abcda29c36fe4afe2c46532 by Antoine Pitrou in branch 'master': bpo-2: Add signal.valid_signals() (GH-6581) https://github.com/python/cpython/commit/9d3627e311211a1b4abcda29c36fe4afe2

[issue33407] Implement Py_DEPRECATED() macro for Visual Studio

Antoine Pitrou <pit...@free.fr> added the comment: In Arrow we use the following: #if __cplusplus <= 201103L # ifdef __GNUC__ # define ARROW_DEPRECATED(...) __attribute__((deprecated(__VA_ARGS__))) # elif defined(_MSC_VER) # define ARROW_DEPRECATED(...) __declspec(deprecated(__

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Antoine Pitrou <pit...@free.fr> added the comment: multiprocessing semaphores support Ctrl-C under Windows, so it should be doable for regular locks as well (notice the `sigint_event`): https://github.com/python/cpython/blob/master/Modules/_multiprocessing/semaphore.c#L10

[issue32608] Incompatibilities with the socketserver and multiprocessing packages

Antoine Pitrou <pit...@free.fr> added the comment: Posted a review now. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32608> ___

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Antoine Pitrou <pit...@free.fr> added the comment: > I'm guessing this is because of the perceived performance impact? The problem is polling is pretty detrimental to power saving on modern CPUs. There might also be a performance impact that makes things worse :-) More generally,

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Antoine Pitrou <pit...@free.fr> added the comment: > One way to possibly make this work (although perhaps not as clean as may be > desired) would be to add polling logic into the thread_nt.h version of > PyThread_acquire_lock_timed. I think adding polling to such a widely

[issue32608] Incompatibilities with the socketserver and multiprocessing packages

Antoine Pitrou <pit...@free.fr> added the comment: Hi Michael, sorry, I haven't had a chance yet. I'll try to make some time soon, I hope you don't mind the delay :-S -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Antoine Pitrou <pit...@free.fr> added the comment: Thanks for the update. Since I still can't reproduce on Linux, perhaps you (or one of our resident Windows experts) can try to propose a patch fixing the issue? -- components: +Windows nosy: +paul.moore, steve.dower, tim.

[issue22393] multiprocessing.Pool shouldn't hang forever if a worker process dies unexpectedly

Antoine Pitrou <pit...@free.fr> added the comment: Oscar, the patch posted here needs updating for the latest git master. If you want to avoid this issue, you can also use concurrent.futures where the issue is fixed. -- stage: -> needs patch versions: +Python 3.8 -P

[issue33329] sigaddset() can fail on some signal numbers

Antoine Pitrou <pit...@free.fr> added the comment: Miro, this should be fixed now. Please reopen if it isn't. The sigfillset() functionality will be exposed to Python users in bpo-2. -- resolution: -> fixed stage: patch review -> resolved status: op

[issue33329] sigaddset() can fail on some signal numbers

Antoine Pitrou <pit...@free.fr> added the comment: New changeset b0ca398cabd2d2ea2d66fa50b08e297a60388c75 by Antoine Pitrou in branch '3.6': [3.6] bpo-33329: Fix multiprocessing regression on newer glibcs (GH-6575) (GH-6582) https://github.com/python/cpython/

<    2   3   4   5   6   7   8   9   10   11   >