[issue11849] glibc allocator doesn't release all free()ed memory

Changes by Charles-François Natali : Removed file: http://bugs.python.org/file21696/gc_trim.diff ___ Python tracker <http://bugs.python.org/issue11849> ___ ___ Python-bug

[issue11849] glibc allocator doesn't release all free()ed memory

Changes by Charles-François Natali : Removed file: http://bugs.python.org/file21858/pymem.diff ___ Python tracker <http://bugs.python.org/issue11849> ___ ___ Python-bug

[issue8498] Cannot use backlog = 0 for sockets

Charles-François Natali added the comment: > To revive this issue, I tried to write a unit test to verify the behaviour. > Onfurtunately, the test doesn't work and I don't understand why. I hope, > someone here is more enlightend than me... The semantic of listen's bac

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

Charles-François Natali added the comment: # A lock taken from the current thread should stay taken in the # child process. Note that I'm not sure of how to implement this. After a fork, even releasing the lock can be unsafe, it must be re-initialized, see following comment in gl

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

Charles-François Natali added the comment: > Yes, we would need to keep track of the thread id and process id inside > the lock. We also need a global variable of the main thread id after > fork, and a per-lock "taken" flag. > > Synopsis: > >    def _reinit_if_nee

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

Charles-François Natali added the comment: Oops, for liunxthreads, you should of course read "different PIDs", not "same PID". -- ___ Python tracker <http://bu

[issue3526] Customized malloc implementation on SunOS and AIX

Charles-François Natali added the comment: > Also that addresses the issue of "two threads inside different malloc > implementations at the same time": it is currently not allowed with > PyMem_Malloc. > That's not true. You can perfectly have one thread inside PyM

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

Charles-François Natali added the comment: >> - what's current_thread_id ? If it's thread_get_ident (pthread_self), >> since TID is not guaranteed to be inherited across fork, this won't >> work > > Ouch, then the approach I'm proposing is probably

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

Charles-François Natali added the comment: Please disregard my comment on PyEval_ReInitThreads and _after_fork: it will of course still be necessary, because it does much more than just reinitializing locks (e.g. stop threads). Also, note that both approaches don't handle synchroniz

[issue8498] Cannot use backlog = 0 for sockets

Charles-François Natali added the comment: > Thanks for the tip. I added the unit test and uploaded my final patch > (which includes all changes). A couple comments (note that I'm not entitled to accept or commit a patch, so feel free to ignore them if I'm just being a pain)

[issue8426] multiprocessing.Queue fails to get() very large objects

Charles-François Natali added the comment: > You can not pickle individual objects larger than 2**31. Indeed, but that's not what's happening here, the failure occurs with much smaller objects (also, note the OP's "cPickle is perfectly capable of pickling these ob

[issue8407] expose signalfd(2) and pthread_sigmask in the signal module

Changes by Charles-François Natali : Removed file: http://bugs.python.org/file21901/pending_signals-2.patch ___ Python tracker <http://bugs.python.org/issue8407> ___ ___

[issue8407] expose signalfd(2) and pthread_sigmask in the signal module

Charles-François Natali added the comment: Oops. Victor, my mouse got stuck and I mistakenly removed your pending_signals-2 patch. I'm really sorry about this, could you re-post it? To try to make up for this, a small comment: In signal_sigwait, at the end of the function, you do

[issue11877] Change os.fsync() to support physical backing store syncs

Charles-François Natali added the comment: > I'll attach 11877.4.diff A couple comments: static PyObject * posix_fsync(PyObject *self, PyObject *args, PyObject *kwargs) { PyObject *retval = NULL; auto PyObject *fdobj; auto int full_fsync = 1; Why are you using the "

[issue12031] subprocess module does not accept file twice

Charles-François Natali added the comment: It's a duplicate of issue #11432: http://bugs.python.org/issue11432 -- nosy: +neologix resolution: -> out of date status: open -> closed superseder: -> webbrowser.open on unix fails. ___

[issue12015] possible characters in temporary file name is too few

Charles-François Natali added the comment: Could someone explain me what's the risk on a case-insensitive filesystem? Since files are created with O_CREAT|O_EXCL, I don't see where the problem is. -- nosy: +neologix ___ Python trac

[issue12015] possible characters in temporary file name is too few

Charles-François Natali added the comment: @Nick I fully agree with you, but my point was that it doesn't make it less safe on case-insensitive filesystems. Apart from that, it's of course better to increase the length of the random

[issue5114] 2.7: test_threading hangs on Solaris

Charles-François Natali added the comment: Hmm. I think this was probably fixed by Gregory in issue #6643 (it's not in Python 2.7.1). Could you try with Python 3.2, or a current snapshot? -- nosy: +neologix ___ Python tracker

[issue8498] Cannot use backlog = 0 for sockets

Charles-François Natali added the comment: The patch looks fine to me: you just need to find someone interested in reviewing and committing it (didn't find anyone listed as expert for the socket module). -- ___ Python tracker

[issue11877] Change os.fsync() to support physical backing store syncs

Charles-François Natali added the comment: Steffen, you changed the default to doing a "full sync" in your last patch: while I was favoring that initially, I now agree with Ronald and Antoine, and think that we shouldn't change the default behaviour. The reason being that A

[issue12044] subprocess.Popen.__exit__ doesn't wait for process end

Charles-François Natali added the comment: There's just one thing I'm concerned with. People using context managers tend to expect the __exit__ method to perform cleanup actions and release corresponding resources if necessary, for example closing the underlying file or socket. So m

[issue12054] test_socket: replace custom _get_unused_port() by support.find_unused_port()

New submission from Charles-François Natali : Lib/test/test_socket.py uses custom _get_unused_port to return a port which will be likely available for binding in some tests. The same functionality is already provided by support.find_unuse_port, let's make use of it. Patch att

[issue12044] subprocess.Popen.__exit__ doesn't wait for process end

Charles-François Natali added the comment: I'm re-opening this issue, since Gregory agrees to change the current behaviour. Patch attached (along with test and documentation update). -- components: +Library (Lib) keywords: +patch resolution: rejected -> status: closed ->

[issue11877] Change os.fsync() to support physical backing store syncs

Charles-François Natali added the comment: Calling fsync on a file descriptor referring to a tty doesn't make much sense. On Linux, this fails with EINVAL: $ python -c 'import os; os.fsync(1)' Traceback (most recent call last): File "", line 1, in OSError: [Errno 22

[issue11877] Change os.fsync() to support physical backing store syncs

Charles-François Natali added the comment: > and if they do they thus really strive for data integrity, so call > fsync() as a fallback for the security which Apple provides. Why? If I ask a full sync and it fails, I'd rather have an error returned so that I can take the appropria

[issue12060] Python doesn't support real time signals

Charles-François Natali added the comment: > If the C signal handler is called twice, the Python signal handler is only > called once. It's not the only shortage with the current implementation regarding (real-time) signals. Another one is that they're delivered out-o

[issue12060] Python doesn't support real time signals

Charles-François Natali added the comment: > Evaluate Python code in a signal handler is really not a good idea! I know, you're limited to async-safe functions, among other things :-) > because of the GIL, I don't think that we can do better. But with the > GIL of Python 3.3, the Python signa

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

Charles-François Natali added the comment: Antoine, I've got a couple questions concerning your patch: - IIUC, the principle is to create a pipe for each worker process, so that when the child exits the read-end - sentinel - becomes readable (EOF) from the parent, so you know that a

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

Charles-François Natali added the comment: > Hi, > Hello Nir, > Option (2) makes sense but is probably not always applicable. > Option (1) depends on being able to acquire locks in locking order, but how > can we determine correct locking order across libraries? > There are indeed a couple p

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

Charles-François Natali added the comment: > Not exactly. The select is done on the queue's pipe and on the workers' > fds *at the same time*. Thus there's no race condition. You're right, I missed this part, it's perfectly safe. But I think there's a pr

[issue8604] Adding an atomic FS write API

Charles-François Natali added the comment: Something's missing in all the implementations presented: to make sure that the new version of the file is available afer a crash, fsync must be called on the containing directory after the rename. -- nosy: +neo

[issue12040] Expose a Process.sentinel property (and fix polling loop in Process.join())

Charles-François Natali added the comment: Just a detail, but with the last version, select is retried with the full timeout (note that the signal you're the most likely to receive is SIGCHLD and since it's ignored by default it won't cause EINTR, so this shouldn't happen

[issue12071] test_concurrent_futures.test_context_manager_shutdown() hangs on OpenIndiana

Charles-François Natali added the comment: Interesting. There's something weird with the first child: === Child #1 = Thread 0x0445: Thread 0x0444: File "/home/haypo/cpython/Lib/threading.py", line 237 in wait waiter.acquire() File "/home/haypo/cpyt

[issue12071] test_concurrent_futures.test_context_manager_shutdown() hangs on OpenIndiana

Charles-François Natali added the comment: This makes sense. I was suspecting a system limit exhaustion, maybe OOM or maximum number of threads, something like that. But at least on Linux, in OOM condition, the process would either get nuked by the OOM-killer, or pthread_create would bail out

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

Charles-François Natali added the comment: Hello Steffen, First, thanks for testing this on OS-X: I only have access to Linux systems (I tested both the semaphore and the emulated semaphore paths). If I understand correctly, the patch works fine with the default build option on OS-X. Then

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

Charles-François Natali added the comment: > Indeed, it isn't, Pipe objects are not meant to be safe against multiple > access. Queue objects (in multiprocessing/queues.py) use locks so they > are safe. But if the write to the Pipe is not atomic, then the select isn't safe.

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

Charles-François Natali added the comment: > a) We know the correct locking order in Python's std libraries so the problem > there is kind of solved. I think that you're greatly under-estimating the complexity of lock ordering. If we were just implementing a malloc implemen

[issue12060] Python doesn't support real time signals

Charles-François Natali added the comment: > if you used the pipe approach you'd need to deal with the case of the > write blocking (or failing if nonblocking) when the pipe buffer is full. Well, a pipe is 64K on Linux (4K on older kernels). Given that each signal received consum

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

Changes by Charles-François Natali : Removed file: http://bugs.python.org/file21991/reinit_locks.diff ___ Python tracker <http://bugs.python.org/issue6721> ___ ___ Pytho

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

Charles-François Natali added the comment: > Is it possible the following issue is related to this one? It's hard to tell, the original report is rather vague. But the comment about the usage of the maxtasksperchild argument reminds me of issue #10332 "Multiprocessing maxtasksper

[issue11877] Change os.fsync() to support physical backing store syncs

Charles-François Natali added the comment: (I'm not sure Rietveld sent the message so I post it here, sorry in case of duplicate). Steffen, I've made a quick review of your patch, in case you're interested. I think that this functionality can be really useful to some people, a

[issue12091] multiprocessing: simplify ApplyResult and MapResult with threading.Event

New submission from Charles-François Natali : Multiprocessing's MapResult and ApplyResult use a notification mechanism to signal callers when the underlying value is available. Instead of re-inventing the wheel, we could use threading.Event instead: this leads to cleaner and simpler code

[issue10239] multiprocessing signal defect

Charles-François Natali added the comment: Closing as duplicate of issue #9205. -- nosy: +neologix resolution: -> duplicate status: open -> closed superseder: -> Parent process hanging in multiprocessing if children terminate une

[issue12096] test_threading.test_waitfor() timeout (1 hour) on x86 Gentoo 3.x buildbot

Charles-François Natali added the comment: The sleep is too short: def f(): with cond: result = cond.wait_for(lambda : state==4) for i in range(5): time.sleep(0.01) with cond: state += 1 cond.notify() If state

[issue6059] ctypes/uuid-related segmentation fault

Charles-François Natali added the comment: It's probably a libc buc, see http://sources.redhat.com/bugzilla/show_bug.cgi?id=12453 Basically, when libraries are dynamically loaded in an interleaved way, this can lead to TLS being returned uninitialized, hence leading to a segfault

[issue12096] test_threading.test_waitfor() timeout (1 hour) on x86 Gentoo 3.x buildbot

Charles-François Natali added the comment: Here's a one-liner patch using the later approach (that way we're sure the test won't hang). -- keywords: +patch Added file: http://bugs.python.org/file22015/wait_for_race.diff ___ Python tracker

[issue12098] Child process running as debug

Charles-François Natali added the comment: Under Linux, child processes are created with fork(), so they're run with the exact same environment as the parent process (among which sys.flags.optimize). I don't know Windows at all, but since I've heard it doesn't have fork(

[issue6059] ctypes/uuid-related segmentation fault

Charles-François Natali added the comment: > Importing uuid before importing the other modules does not result in Seg Fault Alright. In that case, I'm closing this bug as invalid. Until distributions start shipping their glibc with this patch, the workaround is simply to import uu

[issue1746656] IPv6 Interface naming/indexing functions

Charles-François Natali added the comment: Here's a patch: - those functions now accept and return str, not bytes arrays - some of them were not declared static, it's now fixed - use PyErr_SetFromErrno when errno is set - add tests (return type, nonexistent interface name/index a

[issue12105] open() does not able to set flags, such as O_CLOEXEC

Charles-François Natali added the comment: > In python3, one can still use fcntl(f.fileno(), FD_SET, FD_CLOEXEC) Note that it's not atomic. -- nosy: +neologix ___ Python tracker <http://bugs.python.org

[issue12105] open() does not able to set flags, such as O_CLOEXEC

Charles-François Natali added the comment: Here's a patch adding O_CLOEXEC to the os module, with test. This patch makes it possible to open and set a FD CLOEXEC atomically. O_CLOEXEC is part of POSIX.1-2008, supported by the Linux kernel since 2.6.23 and has been committed recent

[issue12105] open() does not able to set flags, such as O_CLOEXEC

Charles-François Natali added the comment: > Using spawn_python() to check that os.O_CLOEXEC flag is correctly set seems > overkill. Why not just testing fcntl.fcntl(f.fileno(), fcntl.F_GETFL) & > FD_CLOEXEC)? Because I couldn't find a place where the CLOEXEC flag was fully tested (I mean, che

[issue12107] TCP listening sockets created without FD_CLOEXEC flag

Charles-François Natali added the comment: Hello Christophe, First and foremost, I think that the FD_CLOEXEC approach is terminally broken, as it should have been the default in Unix. Now, we're stuck with this bad design. But we can't simply change the default to FD_CLOEXEC, for t

[issue12105] open() does not able to set flags, such as O_CLOEXEC

Charles-François Natali added the comment: > To exclude races (in concurrent threads), this two ops should be done under > lock (GIL?) That won't work, because open(), like other slow syscalls, is called without the GIL held. Furthermore, it wouldn't be atomic anyway (imagin

[issue1746656] IPv6 Interface naming/indexing functions

Changes by Charles-François Natali : Removed file: http://bugs.python.org/file22025/socket_if.diff ___ Python tracker <http://bugs.python.org/issue1746656> ___ ___ Pytho

[issue1746656] IPv6 Interface naming/indexing functions

Charles-François Natali added the comment: > You use UTF-8 encoding: Here's an updated patch taking your comments into account (I'm really blissfully ignorant when it comes to encoding issues, so I hope it will be OK this time). -- Added file: http://bugs.python.

[issue12107] TCP listening sockets created without FD_CLOEXEC flag

Charles-François Natali added the comment: > That's not the intention (that's a gordian knot I *will* be keeping > a > safe distance from). The intention is to create a saner default situation > for most python programs. I understand what you're saying, and I agre

[issue1746656] IPv6 Interface naming/indexing functions

Charles-François Natali added the comment: > @neologix: You can commit it into Python 3.3. Tell me if you need > help ;-) My first commit :-) What's the next step? Can this issue be closed, or should I wait until the tests pass on so

[issue1746656] IPv6 Interface naming/indexing functions

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

[issue8035] urllib.request.urlretrieve hangs waiting for connection close after a redirect

Changes by Charles-François Natali : Removed file: http://bugs.python.org/file16758/urllib_redirect.diff ___ Python tracker <http://bugs.python.org/issue8035> ___ ___

[issue8035] urllib.request.urlretrieve hangs waiting for connection close after a redirect

Charles-François Natali added the comment: Those URLs don't trigger the problem anymore, but AFAICT from the code, this problem is still present in py3k. Here's an updated patch. -- Added file: http://bugs.python.org/file22040/urllib_red

[issue1441530] socket read() can cause MemoryError in Windows

Charles-François Natali added the comment: It's actually an obvious case of heap fragmentation due to long-lived chunks being realloc()ed to a smaller size. Some malloc implementations can choke on this (e.g. OS-X's malloc is known to not shrink blocks when realloc() is called with

[issue1441530] socket read() can cause MemoryError in Windows

Changes by Charles-François Natali : Removed file: http://bugs.python.org/file16747/imaplib_read.diff ___ Python tracker <http://bugs.python.org/issue1441530> ___ ___

[issue5715] listen socket close in SocketServer.ForkingMixIn.process_request()

Charles-François Natali added the comment: Thanks for reporting this, the current behaviour is clearly wrong. The child process doesn't need to - and shouldn't - inherit the server socket. The custom idiom when writting such code is to close the new socket (well, in TCP) in the pare

[issue12107] TCP listening sockets created without FD_CLOEXEC flag

Charles-François Natali added the comment: $ cat test_sock.py import socket import fcntl with socket.socket(socket.AF_INET, socket.SOCK_STREAM|socket.SOCK_CLOEXEC) as s: print(bool(fcntl.fcntl(s, fcntl.F_GETFD) & fcntl.FD_CLOEXEC)) $ ./python test_sock.py

[issue1441530] socket read() can cause MemoryError in Windows

Charles-François Natali added the comment: > Patch looks ok. Is 3.x also affected? The I/O stack changed quite a bit in > 3.x. I think it's not affected, but I can't reproduce this behaviour with glibc/eglibc, so don't just take my word for it. The reason is that in py3k, imaplib uses a buffer

[issue1441530] socket read() can cause MemoryError in Windows

Charles-François Natali added the comment: In the buffered reader case, the result buffer is actually pre-allocated with the total size, making fragmentation even less likely. -- ___ Python tracker <http://bugs.python.org/issue1441

[issue1441530] socket read() can cause MemoryError in Windows

Charles-François Natali added the comment: Digging a little deeper, here's the conclusion: - with py3k, fragmentation is less likely: the buffered reader returned by makefile() ensures that we can allocate only one result buffer for the total number of bytes read() (thanks to soc

[issue1441530] socket read() can cause MemoryError in Windows

Changes by Charles-François Natali : Added file: http://bugs.python.org/file22063/imaplib_recv_27.diff ___ Python tracker <http://bugs.python.org/issue1441530> ___ ___

[issue1441530] socket read() can cause MemoryError in Windows

Changes by Charles-François Natali : Removed file: http://bugs.python.org/file22044/imaplib_read.diff ___ Python tracker <http://bugs.python.org/issue1441530> ___ ___

[issue1441530] socket read() can cause MemoryError in Windows

Changes by Charles-François Natali : Removed file: http://bugs.python.org/file22051/imaplib_ssl_makefile.diff ___ Python tracker <http://bugs.python.org/issue1441

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

[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

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