[issue1572968] release GIL while doing I/O operations in the mmap module

Charles-Francois Natali added the comment: As soon as you're dealing with files (not anonymous mapping), you can get the same type of latency than when using open/read/write... While it's probably not worth the trouble to release the GIL for every operation involving mmaped-files, t

[issue2643] mmap_object_dealloc does not call FlushViewOfFile on windows

Charles-Francois Natali added the comment: I don't think that calling msync() or FlushViewOfFile() when closing the mmap object or deallocating it is a good idea. sync()ing dirtied pages to disk is very expensive, blocks the process for a long time, and the OS does a much better job at i

[issue4484] struct: per item endianess specification

Charles-Francois Natali added the comment: I don't see any reasonale reason for mixing endianess inside a struct, and don't know of any real-life protocol using per-item endianess. Unless someone comes up with a good reason for doing so, and since no one else seems to be interest

[issue7978] SocketServer doesn't handle syscall interruption

Charles-Francois Natali added the comment: > If we agree so far, I believe that an implementation of untilConcludes > *should* be added to stdlib ("signal.restartable_call", anyone?). Definitely, it's better to have this handler written once and correct than having va

[issue2643] mmap_object_dealloc does not call FlushViewOfFile on windows

Charles-Francois Natali added the comment: Alright, the current behaviour is quite strange: we don't call msync() when closing the object, we just unmap() it: mmap_close_method(mmap_object *self, PyObject *unused) { [...] #ifdef UNIX if (0 <= self->fd) (void)

[issue2643] mmap_object_dealloc does not call FlushViewOfFile on windows

Changes by Charles-Francois Natali : Added file: http://bugs.python.org/file16828/test_mmap.py ___ Python tracker <http://bugs.python.org/issue2643> ___ ___ Python-bug

[issue8354] siginterrupt with flag=False is reset when signal received

Charles-Francois Natali added the comment: > The effect of signal.siginterrupt(somesig, False) is reset the first time a > that signal is received. This is not the documented behaviour, and I do not > think this is a desireable behaviour. It renders siginterrupt effectively >

[issue8354] siginterrupt with flag=False is reset when signal received

Charles-Francois Natali added the comment: Attached are two patches: - test_signal_siginterrupt.diff is a patch for Lib/test/test_signal.py to check for this problem (more than one signal received after calling signal.siginterrupt()) before: $ ./python Lib/test/regrtest.py test_signal

[issue8354] siginterrupt with flag=False is reset when signal received

Changes by Charles-Francois Natali : Added file: http://bugs.python.org/file16848/signal_noreinstall.diff ___ Python tracker <http://bugs.python.org/issue8354> ___ ___

[issue5315] signal handler never gets called

Charles-Francois Natali added the comment: I think two things can trigger this problem, both have to do with how signals are handled by the interpreter. Contrarily to what you may think, when a signal is received, its handler is _not_ called. Instead, it's Modules/signalmod

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

Charles-Francois Natali added the comment: A couple remarks on BFS-based patch: - nothing guarantees that you'll get a msec resolution - gettimeofday returns you wall clock time: if a process that modifies time is running, e.g. ntpd, you'll likely to run into trouble. the value r

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Charles-Francois Natali added the comment: Signal 32 is the first real-time signal, and is indeed used by linuxthreads, so it's very likely a linuxthreads bug, since this signal shouldn't leak to application. Since linuxthreads is no longer maintained, I'm afraid we can't

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Charles-Francois Natali added the comment: > It looks as though the failed os.execv call messes something up internally, > so that any attempt thereafter to start a thread produces this signal. I > can't see anything obviously wrong with the os.execv implementation (see &g

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

Charles-Francois Natali added the comment: Some more remarks: - COND_TIMED_WAIT macro modifies timeout_result when pthread_cond_timewait expires. But timeout_result is not an int pointer, just an int. So it is never updated, and as a result, bfs_check_depleted is never set after a thread has

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

Charles-Francois Natali added the comment: Please disregard my remark on COND_TIMED_WAIT not updating timeout_result, it's wrong (it's really a macro, not a function...) -- ___ Python tracker <http://bugs.python.

[issue8354] siginterrupt with flag=False is reset when signal received

Charles-Francois Natali added the comment: > Will the modified test fail on platforms that don't define HAVE_SIGACTION? Well, in theory, if the system has siginterrupt but not sigaction, it will fail. But as said, I don't think it's possible, see man siginterrupt: "

[issue8354] siginterrupt with flag=False is reset when signal received

Charles-Francois Natali added the comment: Well, I just think that the probability of having siginterrupt without sigaction is far less than having a Unix system without siginterrupt (which the current test_signal assumes). Or just drop the patch for the test, it honestly doesn't both

[issue8354] siginterrupt with flag=False is reset when signal received

Charles-Francois Natali added the comment: > * There seems to be no good reason to special case SIGCHLD in signal_handler. > The comment about infinite recursion has no obvious interpretation to me. > Fortunately, this is irrelevant on platforms with sigaction, because the

[issue5091] Segfault in PyObject_Malloc(), address out of bounds

Charles-Francois Natali added the comment: It was a long time ago, but: - I think the interpreter will never be able to catch all memory allocation errors, since because of overcommitting (which Linux does), you can very well get a segmentation fault even if the memory allocation routine (be

[issue7332] python script segment fault at PyMarshal_ReadLastObjectFromFile in import_submodule

Charles-Francois Natali added the comment: It's definitely a stack overflow. Most of the backtraces show an important number of frames. The last frame is this: #0 PyMarshal_ReadLastObjectFromFile (fp=0x13e8200) at ../Python/marshal.c:1026 filesize = and a disassembly show us

[issue7332] python script segment fault at PyMarshal_ReadLastObjectFromFile in import_submodule

Changes by Charles-Francois Natali : -- nosy: +ezio.melotti ___ Python tracker <http://bugs.python.org/issue7332> ___ ___ Python-bugs-list mailing list Unsub

[issue7332] python script segment fault at PyMarshal_ReadLastObjectFromFile in import_submodule

Charles-Francois Natali added the comment: > It looks a bit strange for this bug to happen, though. Does Ubuntu use a > small stack size? There are other possible reasons: - the programs that crash (or the libraries they're using) use the stack a lot - somehow, pthread_attr_sets

[issue7332] python script segment fault at PyMarshal_ReadLastObjectFromFile in import_submodule

Charles-Francois Natali added the comment: Ok, I've done too some trivial benchmarking on my Linux box, and I get this: right now: $ time ./python /tmp/test_import.py real0m1.258s user0m1.111s sys 0m0.101s with mmap: $ time ./python /tmp/test_import.py real0m1.262s

[issue7332] python script segment fault at PyMarshal_ReadLastObjectFromFile in import_submodule

Changes by Charles-Francois Natali : Removed file: http://bugs.python.org/file16960/marshal_stack.diff ___ Python tracker <http://bugs.python.org/issue7332> ___ ___ Pytho

[issue7332] python script segment fault at PyMarshal_ReadLastObjectFromFile in import_submodule

Charles-Francois Natali added the comment: The problem is highlighted with recursive imports: a module which imports another module, which imports another module, etc. PyMarshal_ReadLastObjectFromFile is not the only function to use stack-allocated buffers, there are also load_source_module

[issue6600] MemoryError in AiX 64-bit - PyMem_MALLOC fails in open/fdopen

Charles-Francois Natali added the comment: It really looks like a broken compiler: if you want to convince yourself, perform a disassembly of the crashing code. I'd suggest to close this one. -- nosy: +neologix ___ Python tracker

[issue7332] python script segment fault at PyMarshal_ReadLastObjectFromFile in import_submodule

Charles-Francois Natali added the comment: > And that report shows only a single thread, so I have to assume that the 8MB figure applies there. > Nevertheless, we can remove the stack buffer since it's probably useless. It just seems unlikely to me to be the root cause of the sta

[issue7332] python script segment fault at PyMarshal_ReadLastObjectFromFile in import_submodule

Charles-Francois Natali added the comment: > the original report is from the rPath distribution. Never heard of this one, but http://wiki.rpath.com/wiki/rPath_Linux:rPath_Linux_2 states: Compile with --fstack-protectorand FORTIFY_SOURCE=2 (override in your recipes by modifying

[issue8487] os.mknod() fails on NFS mounted directories

Charles-Francois Natali added the comment: > Well, this looks like a filesystem problem more than a Python problem. The error (errno 2) comes from the mknod() system call itself. Definitely. @Nikratio Just to be sure, could you provide the result of: - strace ~/tmp/test.py from NFS-moun

[issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes lag

Charles-Francois Natali added the comment: Yes, performing a DNS resolution every time we log something is definitely sub-optimal. We should perform it only once, and cache the result. -- nosy: +neologix ___ Python tracker <http://bugs.python.

[issue8498] Cannot use backlog = 0 for sockets

Charles-Francois Natali added the comment: That's a non-portable user of listen()'s backlog, see http://www.opengroup.org/onlinepubs/009695399/functions/listen.html: A backlog argument of 0 may allow the socket to accept connections, in which case the length of the listen queue may

[issue8493] socket's send can raise errno 35 under OS X, which causes problems in sendall

Charles-Francois Natali added the comment: The problem is that if you run out of "network buffers" (I guess it's equivalent to Unix socket buffers), what do you do ? If the network or the receiving host is congested, spinning around the send call trying to resend the data

[issue8498] Cannot use backlog = 0 for sockets

Charles-Francois Natali added the comment: It looks like you forgot to update the function's documentation ;-) -- ___ Python tracker <http://bugs.python.org/i

[issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes lag

Charles-Francois Natali added the comment: The attached patch caches the result of FQDN lookup. -- keywords: +patch Added file: http://bugs.python.org/file17079/base_http_server_fqdn_lag.diff ___ Python tracker <http://bugs.python.org/issue6

[issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes lag

Changes by Charles-Francois Natali : Removed file: http://bugs.python.org/file17079/base_http_server_fqdn_lag.diff ___ Python tracker <http://bugs.python.org/issue6

[issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes lag

Charles-Francois Natali added the comment: > Doesn't that only cache the first remote client it encounters, though? Maybe > a dictionary of caches? A BaseHTTPRequestHandler is instantiated every time a client connects, so there should be only one client per handler, no (the

[issue8493] socket's send can raise errno 35 under OS X, which causes problems in sendall

Charles-Francois Natali added the comment: > That's what I thought at first too. But the user's sockets were set to > blocking. That's one broken networking stack... > In fact, I think it's a little silly that OS X raises the error rather than > just saying

[issue8493] socket's send can raise errno 35 under OS X, which causes problems in sendall

Charles-Francois Natali added the comment: > What is the mnemonic corresponding to errno 35 under OS X? (under Linux I get EDEADLOCK, which probably isn't the right one) >From the first message: "errno 35 (resource temporarily unavailable)". It's >actually EAGAI

[issue8493] socket's send can raise errno 35 under OS X, which causes problems in sendall

Charles-Francois Natali added the comment: > I don't see any evidence in support of this statement. >From Microfost Windows' documentation: "The parameter writefds identifies the sockets that are to be checked for writability. If a socket is processing a connect call (n

[issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes lag

Charles-Francois Natali added the comment: @santa4nt: You're correct, the cache is retained only from within the same handler: the other solution would be to keep the cache at the server level, but then you'd have to deal with the cache size (you don't want it to grow forever

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

Charles-Francois Natali added the comment: @dabeaz I'm getting random segfaults with your patch (even with the last one), pretty much everywhere malloc or free is called. Ater skimming through the code, I think the problem is due to gil_last_holder: In drop_gil and take_gil, you derefe

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

Charles-Francois Natali added the comment: I don't see segfaults anymore, but there's still an unsafe dereference of gil_last_holder inside take_gil: /* Wait on the appropriate GIL depending on thread's classification */ if (!tstate->cpu_bound) { /* We are

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

Charles-Francois Natali added the comment: Didn't have much sleep last night, so please forgive me if I say something stupid, but: Python/pystate.c: void PyThreadState_DeleteCurrent() { PyThreadState *tstate = _PyThreadState_Current; if (tstate ==

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

Charles-Francois Natali added the comment: > Do you have any examples or insight you can provide about how these segfaults > have shown up in Python code? I'm not able to observe any such behavior on > OS-X or Linux. Is this happening while running the ccbench program?

[issue1998] documentation grammatical error

New submission from Mick Charles Beaver: On page: http://docs.python.org/lib/sqlite3-Module-Contents.html The following: If you want to use other types, like you have to add support for them yourself. Should be: If you want to use other types, you'll have to add support for them you

[issue1999] wrong tracker

New submission from Mick Charles Beaver: When I found a small mistake in the documentation, I went to the following URL, which in turn sent me to SourceForge, which then sent me to the Roundup bug database. http://docs.python.org/lib/about.html -- components: Documentation messages

[issue3722] print followed by exception eats print with doctest

Charles-Axel Dein <[EMAIL PROTECTED]> added the comment: This is a bug. This is not a good behavior. If I would like to temporarily print a variable to see its content, in order to debug my code, doctest will eat its output. Thus I will be make to use pdb or to use logging, or to get

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

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

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

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

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

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

[issue42401] Plislit does not handle date timezone correctly

New submission from Jean-Charles BERTIN : The plistlib library does not write dates correctly due to its timezone naive date management. For an example, see https://gist.github.com/jcbertin/fedc115ea8122bec9953aa11041294eb or file attached. -- components: Library (Lib), macOS files

[issue42401] Plislit does not handle date timezone correctly

Change by Jean-Charles BERTIN : -- keywords: +patch pull_requests: +22276 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23384 ___ Python tracker <https://bugs.python.org/issu

[issue42401] Plislit does not handle date timezone correctly

Change by Jean-Charles BERTIN : -- components: -macOS ___ Python tracker <https://bugs.python.org/issue42401> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue13778] Python should invalidate all non-owned 'thread.lock' objects when forking

Changes by Charles-François Natali : -- resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> Locks in python standard library should be sanitized on fork ___ Python tracker <http://bugs.python

[issue6774] socket.shutdown documentation: on some platforms, closing one half closes the other half

Charles-François Natali added the comment: > This is questionable, unexpected, and should be documented. There's already this note at the top of the socket module documentation: """ Note Some behavior may be platform dependent, since calls are made to the opera

[issue12760] Add create mode to open()

Charles-François Natali added the comment: Thanks, I've committed your version. -- ___ Python tracker <http://bugs.python.org/issue12760> ___ ___ Pytho

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

Charles-François Natali added the comment: > However, extending RLock to provide ForkClearedRLock (this would be used by > logging, i.e.) is quite straighforward. > > The extended class would simply need to record the process ID, in which the > lock was created, and the proce

[issue13788] os.closerange optimization

Changes by Charles-François Natali : -- resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> subprocess close_fds behavior should only close open fds ___ Python tracker <http://bugs.python

[issue8052] subprocess close_fds behavior should only close open fds

Charles-François Natali added the comment: > Either way, here's a question: does anyone actually know of a unix that does > procfs, and has a daft opendir implementation as described below? Aka, are > we actually worrying about something relevant, or just hypotheticals? I t

[issue13817] deadlock in subprocess while running several threads using Popen

Charles-François Natali added the comment: Here's the backtrace: """ #0 0x003bfb20c9b1 in sem_wait () from /lib64/libpthread.so.0 #1 0x0051a7c3 in PyThread_acquire_lock (lock=0x17db0750, waitflag=1) at Python/thread_pthread.h:321 #2 0x0051a9b

[issue13817] deadlock in subprocess while running several threads using Popen

Charles-François Natali added the comment: Here's the patch. It's probably possible to add a test for this, however I don't have access to my development machine, so I can't write it now. -- Added file: http://bugs.python.org/file2

[issue13703] Hash collision security issue

Charles-François Natali added the comment: > A dict can contain non-orderable keys, I don't know how an AVL tree > can fit into that. They may be non-orderable, but since they are required to be hashable, I guess one can build an comparison function with the following: def cmp(x, y

[issue13703] Hash collision security issue

Charles-François Natali added the comment: > Since we are are trying to fix a problem where hash(X) == hash(Y), you > can't make them orderable by using the hash-values and build a binary > out of the (equal) hash-values. That's not what I suggested. Keys would be considere

[issue13703] Hash collision security issue

Charles-François Natali added the comment: > Yes, that's what I don't understand: How can you do this, when ALL > hash-values are equal. You're right, that's stupid. Short night... -- ___ Python tracker <http

[issue13703] Hash collision security issue

Charles-François Natali added the comment: > So you get the best of both worlds and randomization would only > kick in when it's really needed to keep the application running. Of course, but then the collision counting approach loses its main advantage over randomized hashing: sm

[issue13609] Add "os.get_terminal_size()" function

Charles-François Natali added the comment: > As a Python user (and not a committer), I disagree. > > As an user, I don't care too much where the function should be placed > (although I believe os or sys are sensible choices). What I do care is > that I want a extremely simpl

[issue8713] multiprocessing needs option to eschew fork() under Linux

Charles-François Natali added the comment: I don't know what the others think, but I'm still -1 on this patch. Not that I don't like the principle - it's actually the contrary: in a perfect world, I think this should be made the default -and only - behavior on POSIX. Bu

[issue13812] multiprocessing package doesn't flush stderr on child exception

Charles-François Natali added the comment: > I propose applying the following patch. The test looks good to me (except we don't remove TESTFN explicitely, but I'm not sure it's really necessary). As for the patch, couldn't we put all the file stream flushing in one pl

[issue13812] multiprocessing package doesn't flush stderr on child exception

Charles-François Natali added the comment: LGTM. (I just noticed a bug in Rietveld: when one selects "expand 10 after", the line right after that marker appears duplicated in the new view). -- ___ Python tracker <http://bugs.python.o

[issue13858] readline fails on nonblocking, unbuffered io.FileIO objects

Charles-François Natali added the comment: > Can this be handled some other way? Yeah, that's an hairy issue. See #13322 for the details. -- nosy: +neologix resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> buffered rea

[issue13841] multiprocessing should use sys.exit() where possible

Charles-François Natali added the comment: > * atexit callbacks are NOT run (although multiprocessing.util._exit_function > IS run), It may be a good thing after a fork() (e.g. you don't want to remove the same file twice), but it most definitely looks wrong for a new interpreter

[issue1003195] segfault when running smtplib example

Changes by Charles-François Natali : -- resolution: wont fix -> status: closed -> open ___ Python tracker <http://bugs.python.org/issue1003195> ___ ___ Pyth

[issue13877] segfault when running smtplib example

Charles-François Natali added the comment: > See (permanently closed?) similar bug at: I reopened it. -- nosy: +neologix resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> segfault when running

[issue13891] CPU DoS With Python's socket module

Charles-François Natali added the comment: I don't want to be harsh, but this whole report just doesn't make sense You're getting 90% CPU usage simply because you're flooding your server. Closing. -- nosy: +neologix resolution: -> invalid stage: -> commi

[issue1003195] segfault when running smtplib example

Charles-François Natali added the comment: Could you please indicate exactly the command you're running, and provide the full backtrace? -- nosy: +neologix ___ Python tracker <http://bugs.python.org/issu

[issue13894] threading._CRLock should not be tested if _thread.RLock isn't implemented

Charles-François Natali added the comment: Committed, thanks! -- components: +Tests -Library (Lib) nosy: +neologix resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 3.2 ___ Python track

[issue13817] deadlock in subprocess while running several threads using Popen

Charles-François Natali added the comment: And here's the test. To sum up: - reinit_tls.diff makes sure to call PyThread_ReInitTLS() at the beginning of PyOS_AfterFork(), so that the TLS API is usable within PyOS_AfterFork() (e.g. in _after_fork()). It would be applied to 3.2 and de

[issue13872] socket.detach doesn't mark socket._closed

Changes by Charles-François Natali : -- nosy: +pitrou ___ Python tracker <http://bugs.python.org/issue13872> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue6774] socket.shutdown documentation: on some platforms, closing one half closes the other half

Charles-François Natali added the comment: I've reverted the commit. -- resolution: -> rejected stage: -> committed/rejected status: open -> closed versions: +Python 3.3 ___ Python tracker <http://bugs.pyt

[issue13734] Add a generic directory walker method to avoid symlink attacks

Charles-François Natali added the comment: > Given that, flistdir() and fwalk() seem like the most consistent choices of > name for APIs that aren't directly > matching an underlying POSIX function name. Well, that seems OK for me. I guess the only reason fdlistdir() is nam

[issue13734] Add a generic directory walker method to avoid symlink attacks

Charles-François Natali added the comment: It's to mimic os.walk()'s behavior: http://hg.python.org/cpython/file/bf31815548c9/Lib/os.py#l268 -- ___ Python tracker <http://bugs.python.o

[issue13817] deadlock in subprocess while running several threads using Popen

Changes by Charles-François Natali : -- stage: patch review -> commit review ___ Python tracker <http://bugs.python.org/issue13817> ___ ___ Python-bugs-list mai

[issue13734] Add a generic directory walker method to avoid symlink attacks

Charles-François Natali added the comment: Here are two new versions, both addressing Antoine's and Nick's comments: - fwalk-3.diff is just an updated version - fwalk-single_fd.diff doesn't use more than 2 FDs to walk a directory tree, instead of the depth of directory tree. It&

[issue13734] Add a generic directory walker method to avoid symlink attacks

Charles-François Natali added the comment: > I think the O(depth) version is fine. The O(1) version is quite more > complicated, difficult to follow, and it seems less robust (it doesn't > use try/finally and therefore might leak fds if the generator isn't > exhausted

[issue13817] deadlock in subprocess while running several threads using Popen

Charles-François Natali added the comment: I thought about this a bit more, and I realized that a slight variation of this bug also affects 2.7, and also older versions (i.e. before _PyGILState_Reinit() was introduced), because any code that gets called from PyOS_AfterFork() and uses the TLS

[issue13817] deadlock in subprocess while running several threads using Popen

Charles-François Natali added the comment: Committed. Christoph, thanks for the report. -- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.or

[issue13937] multiprocessing.ThreadPool.join() blocks indefinitely.

Charles-François Natali added the comment: It's a duplicate of issue #12157. -- nosy: +neologix resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> join method of multiprocessing Pool object hangs if iterable argument of

[issue8184] multiprocessing.managers will not fail if listening ocket already in use

Charles-François Natali added the comment: > Well it would probably be closed when the connection object is > destroyed, but the patch looks ok anyway. Let's be nice with those non refcount-based implementations out there :-) What do you think of the patch attached (connection_mult

[issue13806] Audioop decompression frames size check fix

Charles-François Natali added the comment: This broke a sparc buildbot: """ == FAIL: test_alaw2lin (test.test_audioop.TestAudioop) -- Traceba

[issue13878] test_sched failures on Windows buildbot

Charles-François Natali added the comment: """ for x in [0.05, 0.04, 0.03, 0.02, 0.01]: z = scheduler.enter(x, 1, fun, (x,)) """ Since the test uses relative times, if the process is preempted more than 0.01s between two calls to enter (or if the clock goes

[issue13734] Add a generic directory walker method to avoid symlink attacks

Charles-François Natali added the comment: Committed, thanks for the comments. Note to myself (and others that might be interested in the O(1)) version): we can't simply call openat(dirfd, "..", O_RDONLY) to re-open the current directory's file descriptor after having walk

[issue12410] Create a new helper function that enable to test that an operation don't hang more than a given timeout.

Charles-François Natali added the comment: Closing, since it's hard to write correctly, and apparently not that useful. -- resolution: -> rejected stage: -> committed/rejected status: open -> closed ___ Python tracker <http:

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Charles-François Natali added the comment: Closing (see http://bugs.python.org/msg149904 and http://bugs.python.org/msg149909). -- assignee: docs@python -> resolution: -> rejected stage: patch review -> committed/rejected status: open -> closed versions: -Python 2.7

[issue8184] multiprocessing.managers will not fail if listening ocket already in use

Charles-François Natali added the comment: > However, let me point out the following sentence: > “Ports without SO_EXCLUSIVEADDRUSE set may be reused as soon as the socket on > which bind was previously called is closed.” > > ...which seems to suggest we shouldn't us

[issue8184] multiprocessing.managers will not fail if listening ocket already in use

Charles-François Natali added the comment: > I think you read it wrong. Duh, I managed to misread both the comment and the code :-) What my subconscious refused to admit is the fact that on Windows, SO_REUSEADDR allows you to bind to any port - even though the other application didn&#x

[issue13878] test_sched failures on Windows buildbot

Charles-François Natali added the comment: Here's another failure due to the same type of race: """ == FAIL: test_queue (test

[issue13841] multiprocessing should use sys.exit() where possible

Charles-François Natali added the comment: Here's a trivial patch. I run the testsuite on one of the Windows buildbots, and there was one failure, in test_concurrent_futures: """ == FAIL: test_

<    6   7   8   9   10   11   12   13   14   15   >