[issue13322] buffered read() and write() does not raise BlockingIOError

Charles-François Natali added the comment: > Apparently, they are specified to, even for blocking streams (which > I find a bit weird, and the language in the docs seems deliberately > vague). """ As an additional convenience, it attempts to read as many bytes as

[issue13311] asyncore handle_read should call recv

Charles-François Natali added the comment: > Since this patch may break existing valid code, I think it should be > closed as invalid. Yes. Since the benefit is not clear and it may break existing code, it's probably wiser. -- resolution: -> rejected stage: patch revie

[issue13322] buffered read() and write() does not raise BlockingIOError

Charles-François Natali added the comment: > But then what's the point of using buffered I/O at all? If it can't > offer anything more than raw I/O, I'd rather do something like raise > a RuntimeError("buffered I/O doesn't work with non-blocking streams&qu

[issue13342] input() builtin always uses "strict" error handler

Charles-François Natali added the comment: > The bugfix itself is quite pedestrian, but the test is more interesting. Indeed. Looks good to me. -- ___ Python tracker <http://bugs.python.org/issu

[issue4489] shutil.rmtree is vulnerable to a symlink attack

Charles-François Natali added the comment: There's a race: """ --- Lib/shutil.py 2011-11-05 00:11:05.745221315 +0100 +++ Lib/shutil.py.new 2011-11-05 00:11:01.445220324 +0100 @@ -307,6 +307,7 @@ try: mode = os.fstatat(dirfd, name, os.AT_SYMLI

[issue13322] buffered read() and write() does not raise BlockingIOError

Charles-François Natali added the comment: > write() is a bit simpler, since BlockingIOError has > a "characters_written" attribute which is meant to inform you of the > partial success: we can just reuse that. That said, BlockingIOError > could grow a "partial_rea

[issue7777] Support needed for AF_RDS family

Charles-François Natali added the comment: So, what do you think of the new patch? -- ___ Python tracker <http://bugs.python.org/issue> ___ ___ Python-bug

[issue12856] tempfile PRNG reuse between parent and child process

Charles-François Natali added the comment: The patch looks good to me. Note that the whole kill(pid, SIGKILL) looks overkill to me... -- nosy: +neologix ___ Python tracker <http://bugs.python.org/issue12

[issue4489] shutil.rmtree is vulnerable to a symlink attack

Charles-François Natali added the comment: > FYI, I have a pathlib experiment in > http://hg.python.org/features/pathlib/, with an optional openat-based > accessor. Interesting: I used to think that the current API for dealing with paths was a little too basic and terse. Concer

[issue7777] Support needed for AF_RDS family

Charles-François Natali added the comment: Here's an updated patch: - address returned by recvfrom() - recv flags (MSG_PEEK) - congestion behavior I've also added a bunch of constants: - all the typical SO_ constants - CMSG flags - RDMA-related options (RDMA is probably one of the m

[issue11812] transient socket failure to connect to 'localhost'

Charles-François Natali added the comment: > The server thread only waits for 3 seconds for the connection. If a > connection is not created before 3 seconds, the server suicides and when the > connection is tried, it will fail. This probably explain why the problem is > sporad

[issue13303] Sporadic importlib failures: FileNotFoundError on os.rename()

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

[issue7777] Support needed for AF_RDS family

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

[issue13390] Hunt memory allocations in addition to reference leaks

Charles-François Natali added the comment: > Together with -R, it can help chase those memory leaks which aren't > reference leaks (see c6dafa2e2594). Valgrind does a much better job at this: it will also show you where the leaked blocks were allocated. OTOH, Valgrind is Linux-on

[issue13407] tarfile.getnames misses members again

Charles-François Natali added the comment: Isn't this a duplicate of issue #1625? -- nosy: +neologix ___ Python tracker <http://bugs.python.org/is

[issue13215] multiprocessing Manager.connect() aggressively retries refused connections

Charles-François Natali added the comment: Here's a patch removing the automatic retry on ECONNREFUSED: I tested it on Linux and other Unices, and it seems to work just fine without this hammering. Note that there's a similar mechanism for Windows (ERROR_PIPE_BUSY), but it s

[issue13411] Hashable memoryviews

Charles-François Natali added the comment: I'm not sure that the "register" storage class specifier is still relevant with modern compilers: I'm pretty sure gcc ignores it unless -O0, and I think I've read somewhere Microsoft's compiler ignores it to

[issue13422] Subprocess: children hang due to open pipes

Charles-François Natali added the comment: > subprocess.Popen.communicate() hangs for daemonized subprocesses that > leave a pipe open. [...] which leaves stderr pipe open. Of course: the daemon process (spawned by the second fork()) inherits the subprocess's stderr (since file

[issue13215] multiprocessing Manager.connect() aggressively retries refused connections

Charles-François Natali added the comment: > Apparently you forgot to upload the patch... Told you I couldn't think straight :-) -- Added file: http://bugs.python.org/file23720/connection_retry.diff ___ Python tracker <http://bugs

[issue12156] test_multiprocessing.test_notify_all() timeout (1 hour) on FreeBSD 7.2

Charles-François Natali added the comment: Alright, I got tired of seeing the FreeBSD buildbots consistently choke on test_multiprocessing, so here's a simple patch that skips the test if the OS doesn't support a reasonable number (30) of semaphores. -- keywords: +patch

[issue13215] multiprocessing Manager.connect() aggressively retries refused connections

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

[issue12156] test_multiprocessing.test_notify_all() timeout (1 hour) on FreeBSD 7.2

Charles-François Natali added the comment: > Testing os.sysconf("SC_SEM_NSEMS_MAX") value is maybe better than > creating 30 semaphores. Yeah, I thought about that, but the problem is that it doesn't take into account the number of semaphores already allocated: so, for

[issue8270] Should socket.PF_PACKET be removed, in favor of socket.AF_PACKET?

Charles-François Natali added the comment: There are now more protocol families defined (PF_RDS, PF_CAN), etc. Since both AF_ and PF_ are valid (see http://en.wikipedia.org/wiki/Berkeley_sockets#Protocol_and_address_families for more information), and there is so much code out there in the

[issue13156] _PyGILState_Reinit assumes auto thread state will always exist which is not true.

Charles-François Natali added the comment: Alright, should be fixed now. Graham, thanks for the report! -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.or

[issue12156] test_multiprocessing.test_notify_all() timeout (1 hour) on FreeBSD 7.2

Charles-François Natali added the comment: Alright, the test is now skipped when the system doesn't support enough POSIX semaphores. I'm closing, we can still reopen in case another similar problem pops up (on other OS of course). -- resolution: -> fixed stage:

[issue13415] del os.environ[key] ignores errors

Charles-François Natali added the comment: > Oh, it looks like unsetenv() has no return value on Mac OS X Tiger And neither does FreeBSD < 7: http://python.org/dev/buildbot/all/builders/x86%20FreeBSD%206.4%203.x/builds/2015/steps/compile/logs/stdio Note that ignoring unsetenv() return

[issue12578] Erratic socket.gaierror: [Errno 11004] when using smtplib

Changes by Charles-François Natali : -- resolution: -> invalid stage: test needed -> committed/rejected status: pending -> closed ___ Python tracker <http://bugs.python.or

[issue13415] del os.environ

Changes by Charles-François Natali : -- keywords: +needs review stage: -> patch review Added file: http://bugs.python.org/file23764/broken_unsetenv.diff ___ Python tracker <http://bugs.python.org/issu

[issue13422] Subprocess: children hang due to open pipes

Charles-François Natali added the comment: > The problem I have with the solution that is currently implemented is that > subprocess is waiting for the spawned child although the child is not running > anymore. > In my case this issue occured when invoking samba or the small s

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

Charles-François Natali added the comment: > For the record, this seems to make large allocations slower: > > -> with patch: > $ ./python -m timeit "b'x'*20" > 1 loops, best of 3: 27.2 usec per loop > > -> without patch: > $ ./python

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

Charles-François Natali added the comment: > However, there's still another strange regression: > > $ ./python -m timeit \ > -s "n=30; f=open('10MB.bin', 'rb', buffering=0); b=bytearray(n)" \ > "f.seek(0);f.readinto(b)" >

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

Charles-François Natali added the comment: > Hmm, quite slow indeed, are you sure you're not running in debug mode? > Well, yes, but it's no faster with a non-debug build: my laptop is really crawling :-) > If the performance regression is limited to read(), I don'

[issue13481] Use an accurate clock in timeit

Charles-François Natali added the comment: _clocks = ['CLOCK_PROCESS_CPUTIME_ID', 'CLOCK_MONOTONIC_RAW', 'CLOCK_MONOTONIC', 'CLOCK_REALTIME'] Beware, we're mixing CPU time and wall-clock time: $ ./python -c "from time import *;

[issue13481] Use an accurate clock in timeit

Charles-François Natali added the comment: > Indeed. I thought CPU time would be more useful (and that's the point > of the patch) Ah, OK. Then you should probably rename the issue "make timeit measure CPU time", or something like that, because I really thought this is

[issue7111] abort when stderr is closed

Charles-François Natali added the comment: (No Rietveld link): +is_valid_fd(int fd) [...] +dummy_fd = dup(fd); +if (dummy_fd < 0) +return 0; +close(dummy_fd); Why not use fstat() instead (does Windows have fstat()? And dup()?). +@unittest.skipIf(os.name == 'nt

[issue7111] abort when stderr is closed

Charles-François Natali added the comment: > Updated patch. > LGTM. -- ___ Python tracker <http://bugs.python.org/issue7111> ___ ___ Python-bugs-list

[issue13093] Redundant code in PyUnicode_EncodeDecimal()

Charles-François Natali added the comment: A 2.7 OS X buildbot segfaults in test_unicode since 0cd197f13400 : http://www.python.org/dev/buildbot/all/builders/AMD64 Snow Leopard 2 2.7/builds/409/steps/test/logs/stdio """ test_unicode make: *** [buildbottest] Segmentatio

[issue13481] Use an accurate clock in timeit

Charles-François Natali added the comment: > Are CLOCK_MONOTONIC_RAW, CLOCK_MONOTONIC and CLOCK_REALTIME more accurate > than gettimeofday (time.time)? Actually, on Linux gettimeofday() returns CLOCK_REALTIME. As for CLOCK_MONOTONIC{_RAW}, they're guaranteed not to go backward (N

[issue13502] Documentation for Event.wait return value is either wrong or incomplete

Charles-François Natali added the comment: > So I'm changing my mind and saying it seems desireable to return True if the > wait succeeded before the timeout's end, even though the flag may have been > reset in the meantime. Agreed. What matters is that the event has been

[issue12612] Valgrind suppressions

Charles-François Natali added the comment: Could you please provide a diff ? Also, they should probably be commented by default (as other obmalloc-related calls). -- nosy: +neologix ___ Python tracker <http://bugs.python.org/issue12

[issue13390] Hunt memory allocations in addition to reference leaks

Charles-François Natali added the comment: > If someone finds a way to sanitize Valgrind output, Did you use the valgrind suppression file (Misc/valgrind-python.supp)? If yes, then one could simply use --gen-suppressions=yes to add those spurious warning to the suppression file. > a

[issue13517] readdir() in os.listdir not threadsafe on OSX 10.6.8

Charles-François Natali added the comment: > Is there any reason to believe that the problem is confined to OS X? It's a bit of a grey area. Here's what POSIX says: http://pubs.opengroup.org/onlinepubs/009695399/functions/readdir.html """ The pointer returned

[issue13517] readdir() in os.listdir not threadsafe on OSX 10.6.8

Charles-François Natali added the comment: And here's a post by Ulrich Drepper: http://udrepper.livejournal.com/18555.html """ readdir_r is only needed if multiple threads are using the same directory stream. I have yet to see a program where this really is the case. In t

[issue12612] Valgrind suppressions

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

[issue11051] system calls per import

Charles-François Natali added the comment: Here's a trivial patch reducing the number of calls to open. before: """ $ strace -c -e open ./python -c "" % time seconds usecs/call callserrors syscall -- --- --- - ---

[issue13542] Memory leak in multiprocessing.pool

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

[issue11051] system calls per import

Charles-François Natali added the comment: > I would have appreciated had you considered my review before pushing > that change. Sorry, I didn't receive an email notification for your review, so I didn't know you had done one. I&

[issue13502] Documentation for Event.wait return value is either wrong or incomplete

Charles-François Natali added the comment: Here's a patch. -- keywords: +patch Added file: http://bugs.python.org/file23866/event_wait_cleared.diff ___ Python tracker <http://bugs.python.org/issue13502>

[issue13453] Tests and network timeouts

Charles-François Natali added the comment: > URLError: resolution> For this one, we should probably add EAI_FAIL to support.transient_internet. -- keywords: +patch nosy: +neologix Added file: http://bugs.python.org/file23867/transien

[issue11870] test_3_join_in_forked_from_thread() of test_threading hangs 1 hour on "x86 Ubuntu Shared 3.x"

Charles-François Natali added the comment: To debug this, we should probably make use of faulthandler (but not dump_tracebacks_later, since it creates a new thread). The way to go could be to make the parent process send a fatal signal to the child process if the latter takes too long to

[issue13502] Documentation for Event.wait return value is either wrong or incomplete

Charles-François Natali added the comment: > This seems to imply that if the current thread previously set the event, > the wait will return False, which is contradicted by the 'so' statement > (which appears to be correct). You're probably referring to the &q

[issue13555] cPickle MemoryError when loading large file (while pickle works)

Charles-François Natali added the comment: > my computer has 122GB free RAM 122, or 1.22? > Well, replace cPickle by pickle and it works. cPickle makes some direct call to malloc()/realloc()/free(), contrarily to pickle which uses pymalloc. This could lead to heap fragmentation. Wha

[issue13453] Tests and network timeouts

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

[issue10408] Denser dicts and linear probing

Charles-François Natali added the comment: This paper might be of interest: http://www.siam.org/meetings/alenex05/papers/13gheileman.pdf Basically, it concludes that most of the time, there's no speedup to be gained from the increased cached locality incurred by linear probing when the

[issue11870] test_3_join_in_forked_from_thread() of test_threading hangs 1 hour on "x86 Ubuntu Shared 3.x"

Charles-François Natali added the comment: Here's a patch to help nail this down. -- Added file: http://bugs.python.org/file23896/debug_stuck.diff ___ Python tracker <http://bugs.python.org/is

[issue13502] Documentation for Event.wait return value is either wrong or incomplete

Charles-François Natali added the comment: Thanks, here's a patch updated accordingly. -- Added file: http://bugs.python.org/file23897/event_wait_cleared-1.diff ___ Python tracker <http://bugs.python.org/is

[issue13453] Tests and network timeouts

Charles-François Natali added the comment: The test_poplib failures are likely due to this obvious race: """ def setUp(self): [...] threading.Thread(target=self.server, args=(self.evt,self.sock)).start() time.sleep(.1) [...] def server(

[issue13453] Tests and network timeouts

Charles-François Natali added the comment: And I assume that the test_telnetlib failure on the OpenIndiana buildbot is due to a broken name resolution service, as in issue #11812. Here's a patch bumping the timeout to 60s, which should be enough to resolve "localhost"... --

[issue13405] Add DTrace probes

Charles-François Natali added the comment: > Alan, I would open a new issue tracking this one and posting a patch there, > if I were you. > > Previous DTRACE attempts failed because trying to make everybody happy. I > don't want to repeat the mistake. > Sorry, b

[issue13555] cPickle MemoryError when loading large file (while pickle works)

Charles-François Natali added the comment: @Antoine Couldn't this be linked to #11564 (pickle not 64-bit ready)? AFAICT this wasn't fixed in 2.7. Basically, an integer overflow, and malloc() would bail out when asked a ridiculous size. @Philipp I'd be curious to see th

[issue13555] cPickle MemoryError when loading large file (while pickle works)

Charles-François Natali added the comment: @Antoine Couldn't this be linked to #11564 (pickle not 64-bit ready)? Basically, an integer overflow, and malloc() would bail out when asked a ridiculous size. AFAICT this wasn't fixed in 2.7. @Philipp I'd be curious to see th

[issue13555] cPickle MemoryError when loading large file (while pickle works)

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

[issue4028] Problem compiling the multiprocessing module on sunos5

Charles-François Natali added the comment: Thanks Craig. -- resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: -Python 3.1 ___ Python tracker <http://bugs.python.o

[issue11886] test_time.test_tzset() fails on "x86 FreeBSD 7.2 3.x": AEST timezone called "EST"

Charles-François Natali added the comment: Another failure on a 2.7 FreeBSD buildbot: """ test test_time failed -- Traceback (most recent call last): File "/usr/home/db3l/buildarea/2.7.bolen-freebsd7/build/Lib/test/test_time.py", line 193, in test_tzset self

[issue13610] On Python parsing numbers.

Charles-François Natali added the comment: > Can this be fixed? More or less. The following patch does the trick, but is not really elegant: """ --- a/Parser/tokenizer.c2011-06-01 02:39:38.0 + +++ b/Parser/tokenizer.c2011-12-16 08:48:45.

[issue12809] Missing new setsockopts in Linux (eg: IP_TRANSPARENT)

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

[issue13555] cPickle MemoryError when loading large file (while pickle works)

Charles-François Natali added the comment: > So it seems unlikely to be the explanation. Victor reproduced in on IRC, and it's indeed an overflow. The problematic code is in readline_file: """ bigger = self->buf_size << 1; if (bigger

[issue13555] cPickle MemoryError when loading large file (while pickle works)

Charles-François Natali added the comment: Here's a patch which should fix this. However, I'm unable to test it. -- keywords: +patch Added file: http://bugs.python.org/file24006/pickle_overflow.diff ___ Python tracker <http://bu

[issue13555] cPickle MemoryError when loading large file (while pickle works)

Charles-François Natali added the comment: New version. -- Added file: http://bugs.python.org/file24008/pickle_overflow-1.diff ___ Python tracker <http://bugs.python.org/issue13

[issue8684] improvements to sched.py

Charles-François Natali added the comment: This broken the "Fedora without thread buildbot", since sched now requires the threading module: http://www.python.org/dev/buildbot/all/builders/AMD64 Fedora without threads 3.x/builds/1250/steps/test/logs/stdio -- nosy: +neolo

[issue13625] multiprocessing.reduction gives OSError: [Errno 9] in 2.7.2

Charles-François Natali added the comment: Two patches have recently modified this part of the code: http://hg.python.org/cpython/rev/d4d9a3e71897 http://hg.python.org/cpython/rev/cd15473a9de2 I'm unable to reproduce the problem on Linux 3.1.0 x86 with branch 2.7 (for those who would li

[issue11867] Make test_mailbox deterministic

Charles-François Natali added the comment: There was a recent buildbot failure on test_lock_conflict() because of a race. Looking at your patch, I must be missing something, but why not simply use a multiprocessing condition to signal when the parent process has acquired the lock? Otherwise

[issue13625] multiprocessing.reduction gives OSError: [Errno 9] in 2.7.2

Charles-François Natali added the comment: Looking at the strace output: Successful test: sendmsg(11, {msg_name(0)=NULL, msg_iov(1)=[{"\267", 1}], msg_controllen=16, {cmsg_len=16, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, {7}}, msg_flags=0}, 0) = 1 The FD sent is 7 ({7} fie

[issue13625] multiprocessing.reduction gives OSError: [Errno 9] in 2.7.2

Charles-François Natali added the comment: > But I tried building this > http://www.python.org/ftp/python/2.7/Python-2.7.tar.bz2 and that > build worked successfully. This is 2.7, which is more than a year old. The most recent 2.7 version is http://www.python.org/ftp/python/2.7.2/Pyt

[issue13625] multiprocessing.reduction gives OSError: [Errno 9] in 2.7.2

Charles-François Natali added the comment: Alright, thanks! -- resolution: -> out of date stage: -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.or

[issue11870] test_3_join_in_forked_from_thread() of test_threading hangs 1 hour on "x86 Ubuntu Shared 3.x"

Charles-François Natali added the comment: Victor, could you try the patch attached? -- Added file: http://bugs.python.org/file24030/threading_reinit_lock.diff ___ Python tracker <http://bugs.python.org/issue11

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

Charles-François Natali added the comment: Alright, should be fixed now. -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.o

[issue11870] test_3_join_in_forked_from_thread() of test_threading hangs 1 hour on "x86 Ubuntu Shared 3.x"

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

[issue13550] Rewrite logging hack of the threading module

Charles-François Natali added the comment: I'm personally +1 on removing the verbose thing altogether: - it's ugly - I doubt it's really useful (I mean, printing to stderr - which is often line buffered or unbuffered - upon every action will probably change the timing) - it a

[issue13565] test_multiprocessing.test_notify_all() hangs on "AMD64 Snow Leopard 02 03.x"

Charles-François Natali added the comment: I think this could be due to the multiprocessing manager's server socket backlog value, which is a little too low: by default, it's set to 5, and the tests launch up to 3 threads and 3 processes in parallel, so if we're unlucky with

[issue11867] Make test_mailbox deterministic

Charles-François Natali added the comment: > Probably because I'm a threading/multiprocessing neophyte :) That's a very good reason :-) Here's a version using two multiprocessing events. Note that I use timeouts for wait() just to avoid being stuck if something goes wrong:

[issue11867] Make test_mailbox deterministic

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

[issue13453] Tests and network timeouts

Charles-François Natali added the comment: Another failure on an OpenIndiana buildbot: """ == ERROR: testTimeoutConnect (test.test_ftpl

[issue13405] Add DTrace probes

Charles-François Natali added the comment: As I said, I'm skeptical about the benefit vs maintenance burden ratio, especially since cPython doesn't target performance critical applications. I just fear that's a lot of intrusive code which will only be used by a handful of p

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

Charles-François Natali added the comment: > 1. On FreeBSD, we must assume that every blocking system call, in > *every thread*, can be interrupted, and we need to catch EINTR. That's true for every Unix. Every blocking syscall can return EINTR, and there are may non restartab

[issue12708] multiprocessing.Pool is missing a starmap[_async]() method.

Charles-François Natali added the comment: Looks good to me, except for another minor nit: """ the elements of the `iterable` are expected to be tuples """ AFAICT, you just require the elements of `ìterables` to be iter

[issue13645] test_import fails after test_coding

Charles-François Natali added the comment: > a struct timespec providing theoretical nanosecond precision. Indeed. EXT3's timestamps have a 1s granularity, for example. Another possibility would be to store both mtime and st_size (it's the default heuristic used by rsync d

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

Charles-François Natali added the comment: Thanks for the patch sbt. I think this is indeed useful, but I'm tempted to go further and say we should make this the default - and only - behavior. This will probably break existing code that accidentaly relied the fact that the implementation

[issue8604] Adding an atomic FS write API

Charles-François Natali added the comment: I'd like to make this move forward. Milko, I see you have an implementation which looks OK at a first glance. Would like to propose a patch against the default branch? The patch should include documentation and tests. I'm not sure abou

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

Charles-François Natali added the comment: > There is probably lots of such code: > I'm not convinced about making it the default behaviour, and > certainly not the only one. Then I'm not convinced that this patch is useful. Having three different implentations and code

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

Charles-François Natali added the comment: Yes, but it's not easy: the different URLs provided don't demonstrate the behavior anymore (even if we do find such an URL, there's no guarantee it won't change in a couple days/weeks). It could be possible to set up an ad-hoc

[issue8604] Adding an atomic FS write API

Charles-François Natali added the comment: > I prefer to write a "best-effort" function I disagree. People who explicitely use an atomic file API want atomicity/persistency, otherwise they wouldn't use it. Exposing a function that may, or may not, be atomic is just plai

[issue13555] cPickle MemoryError when loading large file (while pickle works)

Charles-François Natali added the comment: Here's a new version with a test (untested). Note that I'm absolutely not sure that the 'memsize' argument to bigmemtest is correct. -- Added file: http://bugs.python.org/file24079/pi

[issue13565] test_multiprocessing.test_notify_all() hangs on "AMD64 Snow Leopard 02 03.x"

Charles-François Natali added the comment: Victor, could you try the attached script on FreeBSD, to see if you get ECONNREFUSED? -- ___ Python tracker <http://bugs.python.org/issue13

[issue1730372] Mesa with NPTL makes Python extensions crash with std::cerr

Charles-François Natali added the comment: I assume this was due to the following bug: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/259219 http://lists.freedesktop.org/archives/mesa-dev/2011-March/006180.html In short, MESA didn't use the correct TLS model for thread-local vari

[issue8604] Adding an atomic FS write API

Charles-François Natali added the comment: > I adhere to "flat is better than nested". e.g. it always irks me to type > "urllib.request" instead of "urllib". Well, that's what (selective) imports are for, no ? from urllib import re

[issue8604] Adding an atomic FS write API

Charles-François Natali added the comment: > Does it have to be a class? What would be the operations apart from > write()? Well, I thought that making it a file-like object could be useful: that way, one could pass it to pickle.dump(), logging.StreamHandler or any method expecting a fil

[issue8604] Adding an atomic FS write API

Charles-François Natali added the comment: > If you want atomicity to apply to logging, > you must instead guarantee the durability of each write() call, meaning > calling fsync() on each logging call Why so? There's no point in calling fsync() after each write, since data i

[issue8623] Aliasing warnings in socketmodule.c

Charles-François Natali added the comment: Thanks for your patches, David. I've only applied the first one: looking at the second one, I don't think they are really problems (-Wstrict-aliasing=2 is know for generating a lot of false positives). -- nosy:

[issue8604] Adding an atomic FS write API

Charles-François Natali added the comment: > Ah, it's a temporary file indeed. > But does that mean you can't inspect your logs in real time? All log > files I have ever seen are available under their final name while they > are still being written to. > Yes, l

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