[issue7946] Convoy effect with I/O bound threads and New GIL

Change by Charles-François Natali : -- nosy: -neologix ___ Python tracker <https://bugs.python.org/issue7946> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12545] os.lseek() and FileIO.seek() does not support offset larger than 2^63-1

Change by Charles-François Natali : -- nosy: -neologix ___ Python tracker <https://bugs.python.org/issue12545> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue17263] crash when tp_dealloc allows other threads

Change by Charles-François Natali : -- nosy: -neologix ___ Python tracker <https://bugs.python.org/issue17263> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12488] multiprocessing.Connection does not communicate pipe closure between parent and child

Change by Charles-François Natali : -- nosy: -neologix ___ Python tracker <https://bugs.python.org/issue12488> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue17852] Built-in module _io can lose data from buffered files in reference cycles

Change by Charles-François Natali : -- nosy: -neologix ___ Python tracker <https://bugs.python.org/issue17852> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use the new F_OFD_SETLK flag)

Change by Charles-François Natali : -- nosy: -neologix ___ Python tracker <https://bugs.python.org/issue22367> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue26692] cgroups support in multiprocessing

Charles-François Natali added the comment: I'm not convinced. The reason is that using the number of CPU cores is just a heuristic for a *default value*: the API allows the user to specify the number of workers to use, so it's not really a limitation. The problem is that if you tr

[issue30014] Speedup DefaultSelectors.modify() by 2x

Charles-François Natali added the comment: The rationale for rejecting wouldn't be "DRY does not apply in this case", it would be that this makes the code more complicated, and that a negligible speedup would not be worth it. Now, thanks to your benchmark, a 10% speedup is not

[issue30014] Speedup DefaultSelectors.modify() by 2x

Charles-François Natali added the comment: This refactoring was already suggested a long time ago, and at the time both Guido and I didn't like it because it makes the code actually more complicated: DRY in this case doesn't apply IMO. Also, this whole thread is a repea

[issue30014] Speedup DefaultSelectors.modify() by 2x

Charles-François Natali added the comment: > I don't think that selector.modify() can be a bottleneck, but IMHO the change > is simple and safe enough to be worth it. In a network server with 10k > client, an optimization making .modify() 1.52x faster is welcomed. IMHO it compli

[issue30014] Speedup DefaultSelectors.modify() by 2x

Charles-François Natali added the comment: Hm, do you have a realistic benchmark which would show the benefit? Because this is really a micro-benchmark, and I'm not convinced that Selector.modify() is a significant bottleneck in a real-world applic

[issue29343] sock.close() raises OSError EBADF when socket's fd is closed

Charles-François Natali added the comment: FWIW I agree with Antoine and Martin: ignoring EBADF is a bad idea, quite dangerous. The man page probably says this to highlight that users shouldn't *retry* close(): """ Retrying the close() after a failure return is t

[issue18966] Threads within multiprocessing Process terminate early

Charles-François Natali added the comment: One reason for not calling sys.exit() is because on Linux, the default implementation uses fork(), hence the address space in the chilren is a clone of the parent: so all atexit handlers, for example, would be called multiple times. There's als

[issue7105] weak dict iterators are fragile because of unpredictable GC runs

Charles-François Natali added the comment: Shouldn't the documentation be updated? https://docs.python.org/3.6/library/weakref.html#weakref.WeakKeyDictionary Note Caution: Because a WeakKeyDictionary is built on top of a Python dictionary, it must not change size when iterating over it.

[issue26601] Use new madvise()'s MADV_FREE on the private heap

Charles-François Natali added the comment: The heap on Linux is still a linear contiguous *address space*. I agree that MADV_DONTNEED allow's returning committed memory back to the VM subsystem, but it is still using a large virtual memory area. Not everyone runs on 64-bit, or can waste ad

[issue26601] Use new madvise()'s MADV_FREE on the private heap

Charles-François Natali added the comment: > Julian Taylor added the comment: > > it defaulted to 128kb ten years ago, its a dynamic threshold since ages. Indeed, and that's what encouraged switching the allocator to use mmap. The problem with dynamic mmap threshold is that si

[issue23992] multiprocessing: MapResult shouldn't fail fast upon exception

Changes by Charles-François Natali : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid -> process mapping.

Charles-François Natali added the comment: Anyone opposed to me committing the patch I submitted? It slves a real problem, and is fairly straight-forward (and conceptually more correct). -- ___ Python tracker <http://bugs.python.org/issue24

[issue23530] os and multiprocessing.cpu_count do not respect cpuset/affinity

Changes by Charles-François Natali : -- stage: needs patch -> resolved status: open -> closed ___ Python tracker <http://bugs.python.org/issue23530> ___ ___

[issue24694] callables registered in TestCase.addCleanup should be run before tearDown

Charles-François Natali added the comment: I understand the risk of breakeage, but that's still broken, because we break LIFO ordering. I'd been using addCleanup() for years and never bothered looking at the documentation - which is admitedly a mistake - because LIFO ordering is t

[issue24694] callables registered in TestCase.addCleanup should be run before tearDown

New submission from Charles-François Natali: Consider this code: - from __future__ import print_function from pyccp.unittest import SafeTestCase class MyTest(SafeTestCase): def setUp(self): print("setUp") def tea

[issue23530] os and multiprocessing.cpu_count do not respect cpuset/affinity

Charles-François Natali added the comment: It's just a doc improvement, I'm not convinced it really needs backporting. -- ___ Python tracker <http://bugs.python.o

[issue23530] os and multiprocessing.cpu_count do not respect cpuset/affinity

Charles-François Natali added the comment: Committed. Julian, thanks for the patch! -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue23992] multiprocessing: MapResult shouldn't fail fast upon exception

Charles-François Natali added the comment: Barring any objections, I'll commit within the next few days. -- ___ Python tracker <http://bugs.python.org/is

[issue23992] multiprocessing: MapResult shouldn't fail fast upon exception

Changes by Charles-François Natali : -- keywords: +needs review nosy: +haypo ___ Python tracker <http://bugs.python.org/issue23992> ___ ___ Python-bugs-list mailin

[issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid -> process mapping.

Changes by Charles-François Natali : -- keywords: +needs review nosy: +haypo ___ Python tracker <http://bugs.python.org/issue24303> ___ ___ Python-bugs-list mailin

[issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid -> process mapping.

Charles-François Natali added the comment: Here's a patch against 2.7 using _PyOS_URandom(): it should apply as-is to 3.3. -- keywords: +patch nosy: +neologix versions: +Python 3.3 Added file: http://bugs.python.org/file39679/mp_sem_race

[issue24427] subclass of multiprocessing Connection segfault upon attribute acces

New submission from Charles-François Natali: The following segfaults in _PyObject_GenericGetAttrWithDict: """ from socket import socketpair from _multiprocessing import Connection class Crash(Connection): pass _, w = socketpair() Crash(w.fileno

[issue23992] multiprocessing: MapResult shouldn't fail fast upon exception

Changes by Charles-François Natali : Added file: http://bugs.python.org/file39172/mp_map_fail_fast_27.diff Added file: http://bugs.python.org/file39173/mp_map_fail_fast_default.diff ___ Python tracker <http://bugs.python.org/issue23

[issue23992] multiprocessing: MapResult shouldn't fail fast upon exception

Changes by Charles-François Natali : Removed file: http://bugs.python.org/file39171/mp_map_fail_fast_default.diff ___ Python tracker <http://bugs.python.org/issue23

[issue23992] multiprocessing: MapResult shouldn't fail fast upon exception

Changes by Charles-François Natali : Removed file: http://bugs.python.org/file39170/mp_map_fail_fast_27.diff ___ Python tracker <http://bugs.python.org/issue23

[issue23992] multiprocessing: MapResult shouldn't fail fast upon exception

Charles-François Natali added the comment: Patches for 2.7 and default. -- keywords: +patch Added file: http://bugs.python.org/file39170/mp_map_fail_fast_27.diff Added file: http://bugs.python.org/file39171/mp_map_fail_fast_default.diff ___ Python

[issue23992] multiprocessing: MapResult shouldn't fail fast upon exception

New submission from Charles-François Natali: hanger.py """ from time import sleep def hang(i): sleep(i) raise ValueError("x" * 1024**2) """ The following code will deadlock on pool.close(): """ from multiprocessing import Pool

[issue23648] PEP 475 meta issue

Charles-François Natali added the comment: > fstat_not_eintr.py: run this script from a NFS share and unplug the network > cable, wait, replug. Spoiler: fstat() hangs until the network is back, CTRL+c > or setitimer() don't interrupt it. You have to mount the share with th

[issue23753] Drop HAVE_FSTAT: require fstat() to compile/use Python

Charles-François Natali added the comment: > Serhiy Storchaka added the comment: > > See also issue12082. Yes, but I don't think we want to clutter the code to support exotic niche platforms. -- ___ Python tracker <http://bugs.pyth

[issue23753] Drop HAVE_FSTAT: require fstat() to compile/use Python

Charles-François Natali added the comment: +1 from me, fstat() has always been par of POSIX. It's really likely Python won't build anyway on such systems. -- ___ Python tracker <http://bugs.python.o

[issue23648] PEP 475 meta issue

Charles-François Natali added the comment: Well, all the syscalls which can blocki can fail with EINTR, so all I:O related one. -- ___ Python tracker <http://bugs.python.org/issue23

[issue23618] PEP 475: handle EINTR in the socket module

Charles-François Natali added the comment: Could you regenerate your latest patch? It doesn't show properly in the review tool. Also, what's with the assert? -- ___ Python tracker <http://bugs.python.o

[issue23694] PEP 475: handle EINTR in fileutils.c

Charles-François Natali added the comment: LGTM. Note that dup() cannot fail with EINTR, it is non-blocking: dup2() can fail, because f the target FD is open, it has to close it, but not dup(). See e.g. this man page from my Debian: EINTR The dup2() or dup3() call was interrupted by a

[issue23646] PEP 475: handle EINTR in the time module, retry sleep()

Charles-François Natali added the comment: As for the change to select/poll/etc, IIRC Guido was opposed to it, that's why I didn't update them. -- ___ Python tracker <http://bugs.python.o

[issue23618] PEP 475: handle EINTR in the socket module

Charles-François Natali added the comment: If EINTR is received during connect, the socket is unusable, that's why i didn't implement it. -- ___ Python tracker <http://bugs.python.o

[issue23285] PEP 475 - EINTR handling

Charles-François Natali added the comment: @Victor: please commit. Would be nice to have a test for it; -- ___ Python tracker <http://bugs.python.org/issue23

[issue23530] os and multiprocessing.cpu_count do not respect cpuset/affinity

Charles-François Natali added the comment: Well, we already expose CPU affinity: >>> import os >>> os.sched_getaffinity(0) {0} IMO the current implementation is sufficient (and talking about overcommitting for CPU is a bit moot if you're using virtual machine

[issue21998] asyncio: support fork

Charles-François Natali added the comment: > @neologix: Would you be ok to add a *private* _at_fork() method to selectors > classes in Python 3.4 to fix this issue? Not really: after fork(), you're hosed anyway: """ Q6 Will closing a file descriptor cause

[issue18932] Optimize selectors.EpollSelector.modify()

Charles-François Natali added the comment: Does anyone have a realistic use case where modify() is actually a non-negligible part? -- ___ Python tracker <http://bugs.python.org/issue18

[issue23285] PEP 475 - EINTR handling

Charles-François Natali added the comment: > Antoine Pitrou added the comment: > >> Would it be possible to push the latest patch right now > > It's ok for me. Please watch the buildbots :) Cool, I'll push o

[issue23351] socket.settimeout(5.0) does not have any effect

Charles-François Natali added the comment: It's a kernel bug closing (working fine on my Debian wheezy with a more recent kernel BTW). -- resolution: -> third party status: open -> closed ___ Python tracker <http://bugs.python.

[issue18932] Optimize selectors.EpollSelector.modify()

Charles-François Natali added the comment: Well, I'd like to see at least one benchmark. -- ___ Python tracker <http://bugs.python.org/issue18932> ___ ___

[issue23351] socket.settimeout(5.0) does not have any effect

Changes by Charles-François Natali : -- status: open -> pending ___ Python tracker <http://bugs.python.org/issue23351> ___ ___ Python-bugs-list mailing list Un

[issue23285] PEP 475 - EINTR handling

Charles-François Natali added the comment: I just realized I didn't retry upon EINTR for open(): eintr-4.diff adds this, along with tests (using a fifo). Also, I added comments explaining why we don't retry upon close() (see e.g. http://lwn.net/Articles/576478/ and http://linux.der

[issue23285] PEP 475 - EINTR handling

Charles-François Natali added the comment: > With eintr-2.diff, fast!: Victory \°/. > Instrumented test_send, 3 socket.send calls, many socket.recv_into calls: Yep, that's expected. I think we should keep the default socket buffer size: it increases the test coverage, and it

[issue23351] socket.settimeout(5.0) does not have any effect

Charles-François Natali added the comment: > The way socket timeouts are implemented is by using select() to determine > whether the socket is ready for read/write. In this case, select() probably > marks the socket ready even though the queue is full, which later raises > EAG

[issue23285] PEP 475 - EINTR handling

Charles-François Natali added the comment: > eintr-1.diff doesn't seem to make any significant difference from eintr.diff > on my system. It's still pegging a CPU at 100% and takes 7 minutes wall time > to complete. Alright, enough played: the patch attached us

[issue23285] PEP 475 - EINTR handling

Charles-François Natali added the comment: OK, it turns out the culprit was repeated calls to BytesIO.getvalue(), which forced large allocations upon reception of every message. The patch attached fixes this (without changing the socket buffer size). -- Added file: http

[issue23285] PEP 475 - EINTR handling

Charles-François Natali added the comment: > Charles-François Natali added the comment: > > Hmmm... > Basically, with a much smaller socket buffer, we get much more context > switches, which increases drastically the test runtime. > But I must admit I'm still really s

[issue23285] PEP 475 - EINTR handling

Charles-François Natali added the comment: > It turns out the times are not important; the hangup is the default size of > the socket buffers on OS X and possibly BSD in general. In my case, the send > and receive buffers are 8192, which explains why the chunks written are so >

[issue23285] PEP 475 - EINTR handling

Charles-François Natali added the comment: > I added a few prints to the send and receive loops of _test_send. When > running on a reasonably current Debian testing Linux: Thanks, that's what I was suspecting, but I really don't understand why 200ms isn't enough for a soc

[issue23267] multiprocessing pool.py doesn't close inqueue and outqueue pipes on termination

Charles-François Natali added the comment: Interestingly, there is no close() method on SimpleQueue... -- nosy: +neologix ___ Python tracker <http://bugs.python.org/issue23

[issue23302] Small fixes around the use of TCP MSS in http.client

Charles-François Natali added the comment: Or we should acknowledge that this is overkill, and take the same approach as all major web browser: disable the Nagle algorithm. For a protocol like http which is transaction oriented it's probably the best thing to do. -- nosy: +neo

[issue23285] PEP 475 - EINTR handling

Charles-François Natali added the comment: > The review diff is weird: it seems it contains changes that aren't > EINTR-related (see e.g. argparse.rst). Here's a manually generated diff. -- Added file: http://bugs.python.org/file

[issue23285] PEP 475 - EINTR handling

Changes by Charles-François Natali : -- title: PEP 475 - EINTR hanndling -> PEP 475 - EINTR handling ___ Python tracker <http://bugs.python.org/issu

[issue23285] PEP 475 - EINTR hanndling

Changes by Charles-François Natali : -- keywords: +patch Added file: http://bugs.python.org/file37797/ff1274594739.diff ___ Python tracker <http://bugs.python.org/issue23

[issue23285] PEP 475 - EINTR hanndling

New submission from Charles-François Natali: The test runs fine on Linux, but hangs in test_send() on OS-X and *BSD. I don't know what's wrong, so if someone with access to one of these OS could have a look, it would be great. -- ___ Pyth

[issue23285] PEP 475 - EINTR hanndling

Changes by Charles-François Natali : -- components: Library (Lib) hgrepos: 293 nosy: haypo, neologix, pitrou priority: normal severity: normal status: open title: PEP 475 - EINTR hanndling type: enhancement ___ Python tracker <http://bugs.python.

[issue23225] selectors: raise an exception if the selector is closed

Charles-François Natali added the comment: RuntimeError sounds better to me (raising ValueError when no value is provided, e.g. in select() sounds definitely strange). -- ___ Python tracker <http://bugs.python.org/issue23

[issue23009] selectors.EpollSelector.select raises exception when nothing to select.

Charles-François Natali added the comment: Thanks for taking care of this. -- ___ Python tracker <http://bugs.python.org/issue23009> ___ ___ Python-bugs-list m

[issue17852] Built-in module _io can loose data from buffered files at exit

Charles-François Natali added the comment: > Serhiy, I believe this still happens in Python 3.4, but it is harder to > reproduce. I couldn't get Armin's script to produce the problem either, but > I'm pretty sure that this is what causes e.g. > https://bugs.debia

[issue22697] Deadlock with writing to stderr from forked process

Charles-François Natali added the comment: > Maries Ionel Cristian added the comment: > > Serhiy, I don't think this is a duplicate. Odd that you closed this without > any explanation. > > This happens in a internal lock in cpython's runtime, while the other bug i

[issue22698] Add constants for ioctl request codes

Charles-François Natali added the comment: Adding ioctl constants is fine. However, I think that if we do this, it'd be great if we could also expose this information in a module (since psutil inclusion was discussed recently), but that's probably ano

[issue18643] add a fallback socketpair() implementation to the socket module

Changes by Charles-François Natali : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed title: add a fallback socketpair() implementation in test.support -> add a fallback socketpair() implementation to the s

[issue22631] Feature Request CAN_RAW_FD_FRAME

Charles-François Natali added the comment: Annoying. I thought CAN_RAW_FD_FRAME would be a macro, which would have made conditional compilation easy, but it's apparently a enum value, which means we have to add a configure-time check... -- components: +Library (Lib

[issue17293] uuid.getnode() MAC address on AIX

Charles-François Natali added the comment: Why is that a different issue? The code you *add in this patch* uses os.popen, why not use subprocess instead? Furthermore, the code catches OSError when calling popen(), but popen() doesn't raise an exce

[issue17293] uuid.getnode() MAC address on AIX

Charles-François Natali added the comment: My only comment would be to use subprocess instead of os.popen(). -- ___ Python tracker <http://bugs.python.org/issue17

[issue22181] os.urandom() should use Linux 3.17 getrandom() syscall

Charles-François Natali added the comment: Note that I'm not fussed about it: far from simplifying the code, it will make it more complex, thus more error-prone. -- ___ Python tracker <http://bugs.python.org/is

[issue21963] 2.7.8 backport of Issue1856 (avoid daemon thread problems at shutdown) breaks ceph

Charles-François Natali added the comment: Agreed with Antoine and Benjamin. -- ___ Python tracker <http://bugs.python.org/issue21963> ___ ___ Python-bugs-list m

[issue17835] test_io broken on PPC64 Linux

Charles-François Natali added the comment: Let's try with this instead: >>> from socket import socket, SO_SNDBUF, SOL_SOCKET >>> s = socket() >>> s.getsockopt(SOL_SOCKET, SO_SNDBUF) -- ___ Python tracker &l

[issue17835] test_io broken on PPC64 Linux

Charles-François Natali added the comment: > In this case, the issues are being caused by the following kernel parameters > that we have for our default build - > > # > ## TIBCO network tuning # > # > net.core.rm

[issue22435] socketserver.TCPSocket leaks socket to garbage collector if server_bind() fails

Charles-François Natali added the comment: Patch attached. The test wouldn't result in FD exhaustion on CPython because of the reference counting, but should still trigger RessourceWarning. -- keywords: +patch nosy: +haypo, pitrou stage: -> patch review Added fi

[issue22378] SO_MARK support for Linux

Charles-François Natali added the comment: Thanks, I committed a simpler version of the patch. -- resolution: -> fixed stage: test needed -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue22127] performance regression in socket getsockaddrarg()

Charles-François Natali added the comment: > Please understand that Victor and I were asking you to pass a *unicode* > object, with a *u* prefix. For me, the time more-than-doubles, on OSX, with > the system python. Sorry, I misread 'b'.

[issue22127] performance regression in socket getsockaddrarg()

Charles-François Natali added the comment: > Charles-François: you get the idna overhead in 2.7, too, by specifying > u'127.0.0.1' as the address. I don't see it in a profile output, and the timing doesn't change whether I pass '12

[issue22127] performance regression in socket getsockaddrarg()

Charles-François Natali added the comment: Parsing a bytes object i.e. b'127.0.0.1' is done by inet_pton(), so it's probably cheap (compared to a syscall). If we had getaddrinfo() and gethostbyname() return bytes instead of strings, it would

[issue22127] performance regression in socket getsockaddrarg()

Charles-François Natali added the comment: > Note that even the bytes version is still quite slow. UDP is used for > light-weight protocols where you may send thousands or more messages per > second. I'd be curious what the sendto() performance is in raw C. Ah, I wouldn't r

[issue22127] performance regression in socket getsockaddrarg()

Charles-François Natali added the comment: OK, I think I see what you mean: $ ./python -m timeit -s "import socket; s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)" "s.sendto(b'hello', ('127.0.0.1', 4242))"1 loops, best of 3: 44.7 usec per loop $

[issue22127] performance regression in socket getsockaddrarg()

Charles-François Natali added the comment: > For Python, the encoder is only used when you pass a Unicode string. Hm... I'm passing ('127.0.0.1', 4242)as destination, and you can see in the above profile that the idna encode function is called. This does

[issue22127] performance regression in socket getsockaddrarg()

Changes by Charles-François Natali : -- title: performance regression in socket.getsockaddr() -> performance regression in socket getsockaddrarg() ___ Python tracker <http://bugs.python.org/issu

[issue22127] performance regression in socket.getsockaddr()

New submission from Charles-François Natali: I noticed that socket.sendto() got noticably slower since 3.4 (at least), compared to 2.7: 2.7: $ ./python -m timeit -s "import socket; s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM); DATA = b'hello'; TARGET=('127.0.0.1

[issue22120] Fix compiler warnings

Changes by Charles-François Natali : -- Removed message: http://bugs.python.org/msg224550 ___ Python tracker <http://bugs.python.org/issue22120> ___ ___ Python-bug

[issue22120] Fix compiler warnings

Charles-François Natali added the comment: This patch should probably be moved to its own issue. -- ___ Python tracker <http://bugs.python.org/issue22120> ___ ___

[issue22110] enable extra compilation warnings

Charles-François Natali added the comment: Committed. Sorry for the extra ~70 warnings :-) -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue17085] test_socket crashes the whole test suite

Charles-François Natali added the comment: Thanks for the reminder Mark. Yes, it is probably still an issue with the latest 2.7 release. There were actually two issues: - send send()/sendall() call didn't block because the test doesn't write enough data: we have since added a SOC

[issue15152] test_subprocess failures on awfully slow builtbots

Charles-François Natali added the comment: Closing, I haven't seen this in a while. -- resolution: -> out of date stage: needs patch -> resolved status: open -> closed ___ Python tracker <http://bugs.pyth

[issue19923] OSError: [Errno 512] Unknown error 512 in test_multiprocessing

Charles-François Natali added the comment: Closing, since it's likely a kernel bug. -- resolution: -> third party stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.pyth

[issue22110] enable extra compilation warnings

Charles-François Natali added the comment: > Antoine Pitrou added the comment: > > Enabling the warnings may be a good incitation for other people to fix them ;) That was my intention... Can I push it, and let warnings be fixed on a case-by-c

[issue22110] enable extra compilation warnings

New submission from Charles-François Natali: The patch attached enables -Wsign-compare and -Wunreachable-code if supported by the compiler. AFAICT, mixed sign comparison warning is automatically enabled by Microsoft's compiler, and is usually a good thing. It does add some warnings though

[issue18174] Make regrtest with --huntrleaks check for fd leaks

Charles-François Natali added the comment: > Richard Oudkerk added the comment: > > I can't remember why I did not use fstat() -- probably it did not occur to me. I probably have Alzeihmer, I was sure I heard a reasonable case for dup() vs fstat(). The only thing I can think of

[issue22054] Add os.get_blocking() and os.set_blocking() functions

Charles-François Natali added the comment: I agree with Akira, although it's probably too late now to rename. -- ___ Python tracker <http://bugs.python.org/is

[issue19875] test_getsockaddrarg occasional failure

Charles-François Natali added the comment: Backported to 2.7 (don't know how Iforgot it). 3.3 is only open for security issues, so not backporting. -- ___ Python tracker <http://bugs.python.org/is

[issue19875] test_getsockaddrarg occasional failure

Charles-François Natali added the comment: Should be fixed now, thanks! -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue22018] Add a new signal.set_wakeup_socket() function

Charles-François Natali added the comment: > It doesn't answer to my complain: I don't want to support file descriptors on > Windows anymore because file descriptors cannot be configured in non-blocking > mode. I think it does : if an exception is raised if an FD/ha

  1   2   3   4   5   6   7   8   9   10   >