Change by Antoine Pitrou <pit...@free.fr>:
--
pull_requests: +6282
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33329>
___
_
Change by Antoine Pitrou <pit...@free.fr>:
--
nosy: +njs
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33329>
___
___
Python
Change by Antoine Pitrou <pit...@free.fr>:
--
keywords: +patch
pull_requests: +6281
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Antoine Pitrou <pit...@free.fr>:
--
nosy: +njs
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue2>
___
___
Python
Antoine Pitrou <pit...@free.fr> added the comment:
New changeset 75a3e3d5bc0be1ce41289b661e7c53039cf3d5ba by Antoine Pitrou (Miss
Islington (bot)) in branch '3.7':
bpo-33329: Fix multiprocessing regression on newer glibcs (GH-6575) (GH-6579)
https://github.com/python/cpython/
Antoine Pitrou <pit...@free.fr> added the comment:
New changeset 25038ecfb665bef641abf8cb61afff7505b0e008 by Antoine Pitrou in
branch 'master':
bpo-33329: Fix multiprocessing regression on newer glibcs (GH-6575)
https://github.com/python/cpython/commit/25038ecfb665bef641abf8cb61afff7505
Change by Antoine Pitrou <pit...@free.fr>:
--
nosy: +neologix
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33329>
___
__
Antoine Pitrou <pit...@free.fr> added the comment:
Not sure what you mean. In the example above, I try to block signals 32 and 33
using pthread_sigmask(), but the pthread_sigmask() return value shows they
weren't blocked, which
Change by Antoine Pitrou <pit...@free.fr>:
--
pull_requests: +6277
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue30750>
___
_
Change by Antoine Pitrou <pit...@free.fr>:
--
keywords: +patch
pull_requests: +6276
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Antoine Pitrou <pit...@free.fr> added the comment:
Right, but it seems that even if sigaddset() allowed you to "set" signals 32
and 33, that would be ignored by pthread_sigmask().
This is what I get here (Ubuntu 16.04, glibc 2.23):
>>> signal.pthread_sigmask(sign
Antoine Pitrou <pit...@free.fr> added the comment:
I don't think we want to be in the business of maintaining a list of
cross-platform of supported signal values. Python may be compiled on bizarre
non-glibc systems (or even systems with a proprietar
Change by Antoine Pitrou <pit...@free.fr>:
--
assignee: -> pitrou
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33329>
___
__
Antoine Pitrou <pit...@free.fr> added the comment:
> Why not export and use the canonical way of
> sigemptyset/sigfillset/sigaddset/sigdelset/sigismember instead of pushing for
> more potential non-conformant code?
I agree this is the proper fix and that's what I plan to d
Antoine Pitrou <pit...@free.fr> added the comment:
Miro, can you give the following patch a try?
diff --git a/Modules/signalmodule.c b/Modules/signalmodule.c
index 7916160..ca76a20 100644
--- a/Modules/signalmodule.c
+++ b/Modules/signalmodule.c
@@ -819,7 +819,6 @@ iterable_to_sigset(Py
Antoine Pitrou <pit...@free.fr> added the comment:
> We could do that, but I'd rather something not multiprocessing-specific
... and also not Linux-specific.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Antoine Pitrou <pit...@free.fr> added the comment:
We could do that, but I'd rather something not multiprocessing-specific. I
think we have to ignore the return value of sigaddset() until issue2 allows
us to be smarter.
--
___
Python t
Antoine Pitrou <pit...@free.fr> added the comment:
Setting as release blocker as it impacts functionality of the multiprocessing
module.
--
nosy: +ned.deily
priority: critical -> release blocker
___
Python tracker <rep...@bugs.python
New submission from Antoine Pitrou <pit...@free.fr>:
See issue33329: it would be nice to expose a signal module function to get the
set of user-actionable signals. Hopefully sigfillset() does that.
--
messages: 315606
nosy: pitrou
priority: normal
severity: normal
stage: needs
Antoine Pitrou <pit...@free.fr> added the comment:
Running the whole test suite sounds fine.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Antoine Pitrou <pit...@free.fr> added the comment:
Miro, could you check whether 2.7 is affected too?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Antoine Pitrou <pit...@free.fr>:
--
priority: normal -> critical
stage: -> needs patch
title: test_multiprocessing_fork, _forkserver, _spawn hangs: ValueError: signal
number 32 out of range -> sigaddset() can fail on some signal numbers
type: -> behavior
Antoine Pitrou <pit...@free.fr> added the comment:
Ok, this is due to:
https://sourceware.org/bugzilla/show_bug.cgi?id=22391
Short explanation here:
https://unix.stackexchange.com/a/155846
--
___
Python tracker <rep...@bugs.python.or
Antoine Pitrou <pit...@free.fr> added the comment:
I was able to compile the program above after the system upgrade using your
Docker image, and the following stands out:
sigaddset(31) returned 0, errno = 0
sigaddset(32) returned -1, errno = 22
sigaddset(33) returned -1, errno = 22
sig
Antoine Pitrou <pit...@free.fr> added the comment:
Perhaps you can compile and run this C program, before and after the system
changes, and post the output:
#include
#include
#include
int main(int argc, char** argv)
{
sigset_t set;
int i, ret;
printf("NSIG =
Antoine Pitrou <pit...@free.fr> added the comment:
This sounds like gratuitous breakage to me. __file__ in particular is used
quite often.
--
nosy: +pitrou
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Antoine Pitrou <pit...@free.fr> added the comment:
There's a test that deliberately kills the semaphore tracker, so that warning
should be expected (I don't see it myself, but that might be because of
differing warning settings).
--
___
Antoine Pitrou <pit...@free.fr> added the comment:
@Benjamin
I can't reproduce here. It's true that test_multiprocessing_fork leaves two
processes being itself, but that doesn't seem to disturb test_subprocess.
@Miro
Could you report the signal number issue separately? Tha
Antoine Pitrou <pit...@free.fr> added the comment:
I'm not convinced by this. One of the points of separating the optimizer from
the compiler is that people wanting to study/extend the compiler don't have to
filter through optimization-related routines. Separating initial code
gene
Change by Antoine Pitrou <pit...@free.fr>:
--
nosy: +serhiy.storchaka
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33270>
___
_
Change by Antoine Pitrou <pit...@free.fr>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
title: Allow memoryview.cast(readonly=...) -> Allow memoryview.toreadonly()
___
Python tracker <rep...@bu
Antoine Pitrou <pit...@free.fr> added the comment:
New changeset 480ab05d5fee2b8fa161f799af33086a4e68c7dd by Antoine Pitrou in
branch 'master':
bpo-33176: Add a toreadonly() method to memoryviews. (GH-6466)
https://github.com/python/cpython/commit/480ab05d5fee2b8fa161f799af33086a4e
Change by Antoine Pitrou <pit...@free.fr>:
--
pull_requests: +6161
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33176>
___
_
Antoine Pitrou <pit...@free.fr> added the comment:
Creating a new PR would be cleaner IMHO.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Antoine Pitrou <pit...@free.fr> added the comment:
> That said, if threads are cheap, why not just create all the work threads on
> initialization, and then remove all the logic entirely?
That would sound reasonable to me. bquinlan has been absent for a long time,
so I wou
Antoine Pitrou <pit...@free.fr> added the comment:
A similar issue for concurrent.futures is bpo-29595.
--
versions: +Python 3.8 -Python 3.4
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Antoine Pitrou <pit...@free.fr> added the comment:
Thanks your contribution Mark!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: -Python 3.6
___
Python tracker <rep...@bugs.
Antoine Pitrou <pit...@free.fr> added the comment:
New changeset b26265900a18a184997c3c3a1fa6a5bf29703ec9 by Antoine Pitrou (Miss
Islington (bot)) in branch '3.7':
bpo-33097: Fix submit accepting callable after executor shutdown by interpreter
exit (GH-6144) (GH-6445)
https://gith
Antoine Pitrou <pit...@free.fr> added the comment:
New changeset c4b695f85e141f57d22d8edf7bc2c756da136918 by Antoine Pitrou (Mark
Nemec) in branch 'master':
bpo-33097: Fix submit accepting callable after executor shutdown by interpreter
exit (GH-6144)
https://github.com/python/cpython/
Antoine Pitrou <pit...@free.fr> added the comment:
Yes, it's a minimal effort. More sophisticated behavior would require a more
sophisticated allocator.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Antoine Pitrou <pit...@free.fr> added the comment:
I pushed a fix for this in 3.8. Since the fix is a bit delicate, I'd rather
not backport it. Thank you for reporting this issue!
--
resolution: -> fixed
stage: patch review -> resolved
status: op
Antoine Pitrou <pit...@free.fr> added the comment:
New changeset e4679cd644aa19f9d9df9beb1326625cf2b02c15 by Antoine Pitrou in
branch 'master':
bpo-32759: Free unused arenas in multiprocessing.heap (GH-5827)
https://github.com/python/cpython/commit/e4679cd644aa19f9d9df9beb1326625cf2
Antoine Pitrou <pit...@free.fr> added the comment:
> Shelve still uses protocol 3 by default. Should it be bumped too?
That sounds reasonable. Perhaps open a separate issue for it?
--
___
Python tracker <rep...@bugs.python
Antoine Pitrou <pit...@free.fr> added the comment:
Side note:
> One concern I do have - while writing the patch, I noticed the existing
> submit method (specifically the adjust_thread_count function) isn't thread
> safe.
True. The executor is obviously thread-safe internally
Antoine Pitrou <pit...@free.fr> added the comment:
> If each worker thread ties up other resources in an application, such as
> handles to server connections, conserving threads could have a significant
> impact.
You may want to implement a pooling mechanism for th
Antoine Pitrou <pit...@free.fr> added the comment:
I'm not fond of this proposal. The existing behaviour is harmless; especially
for a thread pool, since threads are cheap resources. Improving the logic a
bit might seem nice, but it also complicates the executor implementation a bit
Antoine Pitrou <pit...@free.fr> added the comment:
Serhiy, now that protocol 4 is the default, this isn't needed anymore, right?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Antoine Pitrou <pit...@free.fr>:
--
type: -> crash
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33198>
___
___
Antoine Pitrou <pit...@free.fr> added the comment:
I wasn't able to reproduce the test_httplib with gcc 5.4.1 on Ubuntu 16.04.
It would be nice if you could get more information about the crash by printing
the gdb backtrace. It seems there is some help here doing that:
https://gith
Antoine Pitrou <pit...@free.fr> added the comment:
Is there something left to be done here?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Antoine Pitrou <pit...@free.fr>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Antoine Pitrou <pit...@free.fr> added the comment:
New changeset b603609e9dd19268b61b52e701cc0ee8e86784c5 by Antoine Pitrou in
branch '3.6':
[3.6] bpo-33201: Modernize "Extension types" doc (GH-6337) (GH-6412)
https://github.com/python/cpython/commit/b603609e9dd19268b61b52e7
Antoine Pitrou <pit...@free.fr> added the comment:
New changeset 31f1b52f1f6c2d84eacf3c6db3f6b9adf04b675e by Antoine Pitrou (Miss
Islington (bot)) in branch '3.7':
bpo-33201: Modernize "Extension types" doc (GH-6337) (GH-6411)
https://github.com/pytho
Change by Antoine Pitrou <pit...@free.fr>:
--
pull_requests: +6117
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33201>
___
_
Antoine Pitrou <pit...@free.fr> added the comment:
New changeset 1d80a561734b9932961c546b0897405a3bfbf3e6 by Antoine Pitrou in
branch 'master':
bpo-33201: Modernize "Extension types" doc (GH-6337)
https://github.com/python/cpython/commit/1d80a561734b9932961c546b
Antoine Pitrou <pit...@free.fr> added the comment:
I think https://searchcode.com/ may have a larger indexing base than GitHub
alone.
And, yes, you'll see many duplicates of the CPython source code... Visual
inspection may be
Antoine Pitrou <pit...@free.fr> added the comment:
Thanks for the report. Indeed I think it would be worth preventing this
programmer error.
--
nosy: +pitrou
stage: -> needs patch
versions: +Python 3.7, Python 3.8
___
Python tra
Antoine Pitrou <pit...@free.fr> added the comment:
Cheryl: it may be useful to do a code search to find out whether any
third-party projects are relying on PyGen_NeedsFinalizing.
--
___
Python tracker <rep...@bugs.python.or
Change by Antoine Pitrou <pit...@free.fr>:
--
components: +Library (Lib)
stage: -> needs patch
type: -> behavior
___
Python tracker <rep...@bugs.python.org>
<https://bugs.
Antoine Pitrou <pit...@free.fr> added the comment:
> Does anyone seriously write "{*()}" instead of "set()"?
It doesn't seem to be laughing to me.
--
nosy: +pitrou
___
Python tracker <rep...@bugs.python.org>
Change by Antoine Pitrou <pit...@free.fr>:
--
nosy: +inada.naoki, rhettinger
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Antoine Pitrou <pit...@free.fr>:
--
keywords: +patch
pull_requests: +6048
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Antoine Pitrou <pit...@free.fr>:
The "Defining New Types" in the C extension docs uses outdated idioms (e.g.
pre-C99 struct initialization) and could do with a good refresh.
--
assignee: docs@python
components: Documentation
messages: 314782
n
Antoine Pitrou <pit...@free.fr> added the comment:
I'd like to know if the work here will be completed soon :-) This currently
lacks documentation but also tests.
In particular, looking at the code (and that is supported by Will S' comment
above), I feel the API isn't working as intende
Antoine Pitrou <pit...@free.fr> added the comment:
Please note the PR here has some review comments that need addressing.
Also, it needs its conflicts with git master resolved.
I'm cc'ing Thomas Moreau, who has done a lot of work recently on the
concurrent.futures int
Antoine Pitrou <pit...@free.fr> added the comment:
Issue 29595 has a more complete PR, so closing this issue as duplicate.
--
nosy: +pitrou
resolution: -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder: -> Expose max_queue_size in
New submission from Antoine Pitrou <pit...@free.fr>:
It may be useful to get a readonly view of a memoryview.
--
components: Interpreter Core
messages: 314637
nosy: pitrou, skrah
priority: normal
severity: normal
status: open
title: Allow memoryview.cast(readonly=...)
type: enhan
Change by Antoine Pitrou <pit...@free.fr>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Antoine Pitrou <pit...@free.fr> added the comment:
New changeset 6124d8ec0d1eb8016e5e54a4d341b8f4f995623c by Antoine Pitrou (Miss
Islington (bot)) in branch '3.7':
bpo-33126: Document PyBuffer_ToContiguous() (GH-6292) (GH-6294)
https://github.com/python/cpython/
Antoine Pitrou <pit...@free.fr> added the comment:
New changeset 18fdc87207ea65b3906f07cb47c51a609e442f93 by Antoine Pitrou (Miss
Islington (bot)) in branch '3.6':
bpo-33126: Document PyBuffer_ToContiguous() (GH-6292) (GH-6293)
https://github.com/python/cpython/
Antoine Pitrou <pit...@free.fr> added the comment:
Adding Chris Wilcox who wrote the original patch using GetMaximumProcessorCount.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Antoine Pitrou <pit...@free.fr> added the comment:
New changeset aa50bf08e64f49d57917ab0b1aadf4308a3168a6 by Antoine Pitrou in
branch 'master':
bpo-33126: Document PyBuffer_ToContiguous() (#6292)
https://github.com/python/cpython/commit/aa50bf08e64f49d57917ab0b1aadf4308a
Antoine Pitrou <pit...@free.fr> added the comment:
Ok, it seems only PyBuffer_ToContiguous() is worth documenting.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Antoine Pitrou <pit...@free.fr>:
--
pull_requests: +6016
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Antoine Pitrou <pit...@free.fr> added the comment:
> Just to be sure i'm doing the right thing - this thread will be dedicated to
> the os.cpu_count() issue, and i'll open a new issue on the parallelization
> problem.
Exactly.
--
___
Antoine Pitrou <pit...@free.fr> added the comment:
Let's not conflate different issues. The parallelization issue is distinct
from the os.cpu_count() issue (and I'm skeptical Python is at fault there).
--
versions: +Python 3.7, Pyth
Change by Antoine Pitrou <pit...@free.fr>:
--
nosy: +christian.heimes
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33164>
___
_
Antoine Pitrou <pit...@free.fr> added the comment:
> os.cpu_count() reports 128 units
> psutil.cpu_count(logical=False) reports 20 units
> psutil.cpu_count(logical=True) reports 40 units
You mean os.cpu_count() reports *more* CPUs than exist on the machine? How c
Antoine Pitrou <pit...@free.fr> added the comment:
Thanks. The PyBuffer_ToContiguous() API is weird: why pass `len` if it cannot
be anything other than `src->len`?
Also, it would be nice to explain whether the actual buffer data is copied
around (with a memory allocation?) or if
Antoine Pitrou <pit...@free.fr> added the comment:
Thanks for reporting this. I agree this is a real issue, but it doesn't exist
on Python 3 anymore:
>>> q = multiprocessing.Queue()
>>> q.put(1)
>>> q.get()
1
>>> threading.enumerate()
[<_M
New submission from Antoine Pitrou <pit...@free.fr>:
The following C functions are available for C code but not documented:
- PyBuffer_ToContiguous()
- PyBuffer_FromContiguous()
- PyObject_CopyData()
I am not sure how to describe those functions myself.
--
assignee: docs@
Antoine Pitrou <pit...@free.fr> added the comment:
Thanks for spotting this. I will take a look soon, unless someone beats me to
it.
--
nosy: +pitrou
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Antoine Pitrou <pit...@free.fr>:
--
nosy: +tomMoral
versions: +Python 3.7, Python 3.8
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Antoine Pitrou <pit...@free.fr> added the comment:
> I would suggest that a simper interpreter with smaller, simpler bytecodes is
> a worthy goal in itself.
+1 from me. Though I'm curious about performance changes as well :-)
--
n
Antoine Pitrou <pit...@free.fr> added the comment:
Good, I think we can close again now!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Antoine Pitrou <pit...@free.fr> added the comment:
New changeset bb5b5291971c104ea773db1a30e46d410b6b3e1e by Antoine Pitrou (Miss
Islington (bot)) in branch '3.7':
bpo-33078 - Fix queue size on pickling error (GH-6119) (GH-6178)
https://github.com/python/cpython/
Change by Antoine Pitrou <pit...@free.fr>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Change by Antoine Pitrou <pit...@free.fr>:
--
versions: -Python 2.7, Python 3.5, Python 3.6
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Antoine Pitrou <pit...@free.fr> added the comment:
New changeset e2f33add635df4fde81be9960bab367e010c19bf by Antoine Pitrou
(Thomas Moreau) in branch 'master':
bpo-33078 - Fix queue size on pickling error (GH-6119)
https://github.com/python/cpython/
Antoine Pitrou <pit...@free.fr> added the comment:
I don't really agree that "callbacks are really important in multiprocessing"
(I think I've hardly ever used them). I agree with the other doc changes in
the PR.
--
___
Pyt
Change by Antoine Pitrou <pit...@free.fr>:
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bugs.
Antoine Pitrou <pit...@free.fr> added the comment:
New changeset f3e6eadbcf4f3e0fe53f4784485b1c8464c7d282 by Antoine Pitrou (Miss
Islington (bot)) in branch '3.6':
[3.6] bpo-33021: Release the GIL during fstat() calls (GH-6019) (GH-6160)
https://github.com/python/cpython/
Antoine Pitrou <pit...@free.fr> added the comment:
New changeset 56cce1ca84344f519f7ed01024434c083031d354 by Antoine Pitrou (Miss
Islington (bot)) in branch '3.7':
[3.7] bpo-33021: Release the GIL during fstat() calls (GH-6019) (GH-6159)
https://github.com/python/cpython/
Antoine Pitrou <pit...@free.fr> added the comment:
Reopening for 3.x backports, as per Robert's advice.
--
status: closed -> open
versions: +Python 3.6, Python 3.7
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Antoine Pitrou <pit...@free.fr> added the comment:
With Benjamin we've decided that this wouldn't happen in 2.7. Performance
improvements don't warrant a backport.
Thank you Nir for reporting and posting the patches!
--
resolution: -> fixed
stage: patch review -> res
Antoine Pitrou <pit...@free.fr> added the comment:
New changeset d6e140466142018ddbb7541185348be2b833a2ce by Antoine Pitrou
(Zackery Spytz) in branch 'master':
bpo-33021: Fix GCC 7 warning (-Wmaybe-uninitialized) in mmapmodule.c (#6117)
https://github.com/python/cpython/
Antoine Pitrou <pit...@free.fr> added the comment:
The expected behaviour here would be to raise ValueError, as on other closed
objects:
>>> s = io.StringIO()
>>> s.close()
>>> s.write("")
Traceback (most recent call last):
File "",
Change by Antoine Pitrou <pit...@free.fr>:
--
components: +Library (Lib) -ctypes
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Antoine Pitrou <pit...@free.fr> added the comment:
I cannot reproduce this on Ubuntu 16.04.
--
nosy: +belopolsky, paul.moore, pitrou, steve.dower, tim.golden, zach.ware
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Antoine Pitrou <pit...@free.fr> added the comment:
Please, can you post a self-contained script to reproduce the issue?
--
nosy: +pitrou
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
701 - 800 of 16564 matches
Mail list logo
