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

Charles-François Natali added the comment: [...] > A caveat is that since Python is an object oriented language it is more > common than with C that code from a higher level module will be invoked by > code from a lower level module, for example by calling an object method that &

[issue12469] test_faulthandler failures on FreeBSD 6

Charles-François Natali added the comment: > When signals are unblocked, pending signal ared delivered in the reverse order > of their number (also on Linux, not only on FreeBSD 6). I don't like this. POSIX doesn't make any guarantee about signal delivery order, except for r

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

Charles-François Natali added the comment: > Except for multiprocessing, does anyone know of any other module in the > standard library that uses fork() and threads at the > same time? After some grepping through the source I couldn't find any other > cases. The same probl

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

Charles-François Natali added the comment: >> We can't do that, it would break existing code. > > I would argue that such code is already broken. > - that's not necessarily true, if your code is carefully designed - we can't forbid fork() in a multi-threaded app

[issue12502] 100% cpu usage when using asyncore with UNIX socket

Charles-François Natali added the comment: It's looping in Lib/asyncore.py:poll select(4, [3], [3], [3], {30, 0}) = 1 (out [3], left {29, 94}) select(4, [3], [3], [3], {30, 0}) = 1 (out [3], left {29, 94}) select(4, [3], [3], [3], {30, 0}) = 1 (out [3], lef

[issue12493] subprocess: Popen.communicate() doesn't handle EINTR in some cases

Charles-François Natali added the comment: Out of curiosity, how could SIGALRM be missing on a Unix system? Maybe you mean something like @unittest.skipUnless(hasattr(errno, EINTR), "Requires errno.EINTR") -- nosy:

[issue12181] SIGBUS error on OpenBSD (sparc64)

Charles-François Natali added the comment: > @neologix: New try. Why did you remove your patch? > Sorry, I completely forgot about this issue. Because it was incorrect (it would have fixed the SIGBUS, but would have produced incorrect results). IIRC, the problem is that those members ar

[issue12502] 100% cpu usage when using asyncore with UNIX socket

Charles-François Natali added the comment: > Looks good, the patch seems to fix the problem. Alright. Giampaolo, do you agree? Also, I noticed that test_asyncore currently only tests AF_INET sockets. I'm working a patch to add AF_UNIX (and maybe AF_INET

[issue12326] Linux 3: tests should avoid using sys.platform == 'linux2'

Charles-François Natali added the comment: > @neologix: I don't understand why do you want to hurry, this issue will not > be fixed in the next release (3.2.1, it's too late), and I don't think that > the next release (3.3? or is it something before?) will come befor

[issue12539] multiprocessing.Event.wait(n) doesn't time out properly

Charles-François Natali added the comment: Are you using a 2.6.38 kernel? There was a regression in early 2.6.38 kernels that caused FUTEX_WAIT with a timeout to never return after a suspend-resume, see: https://lkml.org/lkml/2011/4/13/23 It's been fixed by this commit: http://git.kerne

[issue12539] multiprocessing.Event.wait(n) doesn't time out properly

Charles-François Natali added the comment: >> Are you using a 2.6.38 kernel? > Yes Alright, closing as invalid then. -- resolution: -> invalid stage: -> committed/rejected status: open -> closed ___ Python tracker <h

[issue12545] Incorrect handling of return codes in the posix_lseek function in posixmodule.c

Charles-François Natali added the comment: > In the posix_lseek function check for result != -1 instead of checking > for result < 0 in return code checks of the value returned by lseek. +1 This can be useful when parsing /dev/mem on x86_64, for example. > In addition I wo

[issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE

Charles-François Natali added the comment: Brian, any comment about the Windows part (see Victor's message, http://bugs.python.org/issue12287#msg138137) ? -- nosy: +brian.curtin ___ Python tracker <http://bugs.python.org/is

[issue12502] 100% cpu usage when using asyncore with UNIX socket

Charles-François Natali added the comment: Patch committed, closing. Alexey, thanks for reporting this. (I'll open a separate issue to increase the tests coverage). -- resolution: -> fixed stage: -> committed/rejected status: ope

[issue12326] Linux 3: tests should avoid using sys.platform == 'linux2'

Charles-François Natali added the comment: Here we go, first Linux3-related bug report: https://bugs.gentoo.org/show_bug.cgi?id=374579 (see issue #12571). -- ___ Python tracker <http://bugs.python.org/issue12

[issue12556] Disable size checks in mmap.mmap()

Charles-François Natali added the comment: A couple remarks: - if st_size == 0, then you have to specify an explicit length (your example passes 0, which would fail with EINVAL without the check) - most enties in /proc don't support mmap file operation, so it's likely to fail an

[issue12545] Incorrect handling of return codes in the posix_lseek function in posixmodule.c

Charles-François Natali added the comment: > So even on solaris the behavior seems to be filesystem dependent. > So I'd suggest forgetting about this part. Would you like to write a patch for the first point? -- ___ Python tra

[issue12372] semaphore errors on AIX 7.1

Charles-François Natali added the comment: So, what do we do now? -- ___ Python tracker <http://bugs.python.org/issue12372> ___ ___ Python-bugs-list mailin

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

Charles-François Natali added the comment: Trying to revive this issue, here's a comment I left on Rietveld: """ > I don't agree, the documentation states that full_sync will cause a flush to > stable storage where supported and a plain fsync where it isn'

[issue12372] semaphore errors on AIX 7.1

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

[issue12326] Linux 3: tests should avoid using sys.platform == 'linux2'

Charles-François Natali added the comment: > I'm still in favor of keeping sys.platform == 'linux3', and you? > So do I. > For plat-linux3, should we regenerate this directory (I cannot do that, I > don't have Linux 3.0 yet) or can we just use a symbolic link?

[issue12545] Incorrect handling of return codes in the posix_lseek function in posixmodule.c

Charles-François Natali added the comment: > Hi.  I can submit a patch for the first part.  Should I submit on this issue > tracker item? > Sure. -- ___ Python tracker <http://bugs.python.or

[issue12372] semaphore errors on AIX 7.1

Charles-François Natali added the comment: Patch committed: this should fix POSIX semaphores failures on AIX. Reshmi, thanks for reporting this! -- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _

[issue12556] Disable size checks in mmap.mmap()

Charles-François Natali added the comment: > By the way, I've checked mmap(2) manpage -- it looks like the C-version has > nothing > against mmaping 0-sized files, Why does Python's `mmap` still checks file > size? It doesn't check explicitely that the size is non-0,

[issue12326] Linux 3: tests should avoid using sys.platform == 'linux2'

Charles-François Natali added the comment: > Still -1. It should be renamed to 'linux' in future releases, and > back-patched to 'linux2' for maintenance releases. > I really don't see any advantage to this solution: - sys.platform currently has a clear and

[issue12545] Incorrect handling of return codes in the posix_lseek function in posixmodule.c

Charles-François Natali added the comment: Patch attached. > For lseek, we can rely on errno. Try something like that: > > errno = 0; > offset = lseek(...); > if (offset == (off_t)-1 && errno) /* error */ > It's a little bit overkill :-) (for mktime, time_

[issue12592] modify configure.in to detect OpenBSD 5.x

Charles-François Natali added the comment: Patch attached (this one should also work with future major releases). -- keywords: +needs review, patch nosy: +neologix, pitrou stage: -> patch review Added file: http://bugs.python.org/file22720/configure_openbsd.d

[issue12588] test_capi.test_subinterps() failed on OpenBSD (powerpc)

Charles-François Natali added the comment: > Previous frame inner to this frame (corrupt stack?) Interesting. Could you post the result of: $ valgrind --tool=memcheck --suppressions=Misc/valgrind-python.supp Modules/_testembed after having un-commented the ADDRESS_IN_RANGE suppressi

[issue12592] modify configure.in to detect OpenBSD 5.x

Charles-François Natali added the comment: Patch committed. Rémi, thanks for reporting this (and other OpenBSD-specific bugs :-). -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python track

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

Charles-François Natali added the comment: > One could argue that something had happened before the fsync(2), > so that code which blindly did so is too dumb to do any right > decision anyway. Even PEP 3151 won't help. I don't understand. If the syscall supposed

[issue8714] Delayed signals in the REPL on OpenBSD (possibly libpthread related)

Charles-François Natali added the comment: > This behavior was introduced (exposed by?) r68460. After a quick look, I don't see anything wrong with r68460, but it might very well have exposed this problem which was lurking before. > When Python is compiled without threads, the

[issue12620] pending calls: make `pendingbusy` flag static to Py_MakePendingCalls()

New submission from Charles-François Natali : Trivial patch. In Python/ceval.c, when compiled with threads, make the `pendingbusy` flag used to guard against reentrant calls static to Py_MakePendingCalls(). Also, make it an int and rename it to `busy` to be consistent with the non-threaded

[issue12588] test_capi.test_subinterps() failed on OpenBSD (powerpc)

Charles-François Natali added the comment: and Darwin). It would have been useful... """ interp 0x0, thread state 0x81855380: Program received signal SIGSEGV, Segmentation fault. """ Here, the interpreter state is NULL, and this shouldn't happen. It co

[issue12620] pending calls: make `pendingbusy` flag static to Py_MakePendingCalls()

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

[issue12603] pydoc.synopsis breaks if filesystem returns mtime of 0

Charles-François Natali added the comment: Demo: """ cf@neobox:~/cpython$ ./python -c "import pydoc; print(pydoc.synopsis('Lib/os.py'))" OS routines for Mac, NT, or Posix depending on what system we're on. [51835 refs] cf@neobox:~/cpython$ touch -t 197

[issue12625] sporadic test_unittest failure

Charles-François Natali added the comment: Looks similar to issue #8263, which is in turn similar to #12469 (see http://bugs.python.org/issue12469#msg139620 and http://bugs.python.org/issue12469#msg139626 for original explanations): normally, pending signals are checked when the process

[issue12603] pydoc.synopsis breaks if filesystem returns mtime of 0

Charles-François Natali added the comment: Well, the function is part of pydoc's public API, but the inner working of the cache mechanism is completely private: this won't have any impact, other than fixing the bug :-) -- ___ Python trac

[issue12625] sporadic test_unittest failure

Charles-François Natali added the comment: > So I'd say the easier solution is to skip this test on OpenSolaris, > like it's done on FreeBSD6 since issue #8263. Another option could be to add a dummy syscall, like os.getpid(), before checking that the handler got called - this

[issue12625] sporadic test_unittest failure

Charles-François Natali added the comment: > No, it's a feature of the new GIL. When I look at 2.7's code, I see something different - _Py_Ticker is reset in Py_AddPendingCall(): int Py_AddPendingCall(int (*func)(void *), void *arg) { [...] /* signal main loop */ _

[issue12560] libpython.so not built on OpenBSD

Charles-François Natali added the comment: The patch looks good to me. As for the other failures, it would probably be interesting to open a separate issue, no? -- ___ Python tracker <http://bugs.python.org/issue12

[issue12560] libpython.so not built on OpenBSD

Charles-François Natali added the comment: Patch committed. Stefan, thanks for the report and the patch! -- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed ___ Python tracker <http://bug

[issue12498] asyncore.dispatcher_with_send, disconnection problem + miss-conception

Charles-François Natali added the comment: Hello, > Actually the class asyncore.dispatcher_with_send do not handle properly > disconnection. When the endpoint shutdown his sending part of the socket, > but keep the socket open in reading, the current implementation of > dispatch

[issue12498] asyncore.dispatcher_with_send, disconnection problem + miss-conception

Changes by Charles-François Natali : -- components: +Library (Lib) -IO stage: -> needs patch type: -> behavior versions: +Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/i

[issue10141] SocketCan support

Charles-François Natali added the comment: Thanks for updating your patch. I've done a review, available here: http://bugs.python.org/review/10141/show -- ___ Python tracker <http://bugs.python.org/is

[issue11784] multiprocessing.Process.join: timeout argument doesn't specify time unit.

Charles-François Natali added the comment: Committed to default. Patrick, thanks for the patch! -- nosy: +neologix resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: -Python 2.7 ___ Pytho

[issue12625] sporadic test_unittest failure

Charles-François Natali added the comment: > Please write a function (in test.support?) with a comment explaining why you > are doing that. > You may also only do this workaround on specific platforms. For example, > only on FreeBSD and OpenIndiana (the test would be in the functio

[issue12463] Calling SocketServer.shutdown() when server_forever() was not called will hang

Charles-François Natali added the comment: Seems reasonable to me. What bothers me is this comment in shutdown's docstring: """Stops the serve_forever loop. Blocks until the loop has finished. This must be called while serve_forever() is running i

[issue6419] Broken test_kqueue.py on OpenBSD

Charles-François Natali added the comment: Stephan, did you apply the patch? I think the failures you were experiencing on amd64 could be due to issue #12181: OpenBSD's struct kevent definition differs from FreeBSD/NetBSD, which can trigger a segfault on sparc64 (which doesn&#x

[issue12464] tempfile.TemporaryDirectory.cleanup follows symbolic links

Charles-François Natali added the comment: I'm not sure I see what the problem is: - if the idea behind this is the risk of symlink attack (like issue #4489), it's not the case here, because the directory is created with 0600 permission - furthermore, the attached patch has a TO

[issue11871] test_default_timeout() of test_threading.BarrierTests failure: BrokenBarrierError

Charles-François Natali added the comment: The attached patch bumps the barrier's default timeout to 300ms: it should be more than enough (unless you got a really crappy scheduler, or a really heavily loaded machine), especially since this problem doesn't seem to occur ofte

[issue12464] tempfile.TemporaryDirectory.cleanup follows symbolic links

Charles-François Natali added the comment: > I agree with Antoine - it's a simple bug Alright, in that case I agree (I thought this was considered as a security issue). Two comments on the patch: Lib/tempfile.py: # Don't recurse to symlinked directories (issue #12464)

[issue3526] Customized malloc implementation on SunOS and AIX

Charles-François Natali added the comment: > Fortunately, it is easy to solve by defining the following in > dlmalloc: > #define HAVE_MORECORE 0 I was expecting this answer ;-) Here's a quick demo, on a Linux box: cf@neobox:~/cpython$ ./python Tools/pybench/p

[issue12464] tempfile.TemporaryDirectory.cleanup follows symbolic links

Charles-François Natali added the comment: > If someone suggests how to test for the Windows version, I'll update > the patch, also to remove the issue reference from the code. Well, I don't know Windows, but there's platform.win32_ver() (http://docs.python.org/

[issue12463] Calling SocketServer.shutdown() when server_forever() was not called will hang

Charles-François Natali added the comment: When you join a thread which hasn't been started, you get an exception, not a deadlock. When you join a newly-created queue, it doesn't wait until an item is submitted to the queue. But honestly I don't really care, since it's such

[issue12181] SIGBUS error on OpenBSD (sparc64)

Charles-François Natali added the comment: > patch-Modules_selectmodule_c is not enough to fix kqueue_event_init(): it > doesn't catch overflow error on the ident attribute. This patch is not correct. Furthermore, it's another occurrence of something I don't understa

[issue12181] SIGBUS error on OpenBSD (sparc64)

Charles-François Natali added the comment: > I wrote the patch. While the patch fixes most of the issues I'm not entirely > happy with it and that's the reason I have not submitted it. Could you submit it here so that we can help you get it in shape for inclusion? That way w

[issue12464] tempfile.TemporaryDirectory.cleanup follows symbolic links

Charles-François Natali added the comment: The patch looks good to me. -- ___ Python tracker <http://bugs.python.org/issue12464> ___ ___ Python-bugs-list mailin

[issue11871] test_default_timeout() of test_threading.BarrierTests failure: BrokenBarrierError

Charles-François Natali added the comment: Victor, can I commit it? -- ___ Python tracker <http://bugs.python.org/issue11871> ___ ___ Python-bugs-list mailin

[issue5113] 2.5.4.3 / test_posix failing on HPUX systems

Charles-François Natali added the comment: Patch attached. -- keywords: +needs review, patch stage: -> patch review versions: +Python 3.2, Python 3.3 Added file: http://bugs.python.org/file22780/chown_hpux.diff ___ Python tracker &l

[issue12603] pydoc.synopsis breaks if filesystem returns mtime of 0

Charles-François Natali added the comment: Committed. Josh, thanks for the report. -- resolution: -> fixed stage: patch review -> committed/rejected ___ Python tracker <http://bugs.python.org/i

[issue12603] pydoc.synopsis breaks if filesystem returns mtime of 0

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

[issue11871] test_default_timeout() of test_threading.BarrierTests failure: BrokenBarrierError

Charles-François Natali added the comment: > YES YOU CAN :-) -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: +Python 3.2 ___ Python tracker <http://bugs.python

[issue12650] Subprocess leaks fd upon kill()

Charles-François Natali added the comment: There's indeed a leak in your code, because you don't close the stdout and stderr file descriptors. Try with: subp.terminate() subp.stdout.close() subp.stderr.close() return True And you'll be just fine. The reason

[issue12650] Subprocess leaks fd upon kill()

Charles-François Natali added the comment: Alright. I tested this on default, and couldn't reproduce the FD leak. It turned out to be due to another bug, affecting only the code path which calls pure C _posixsubprocess (which is the only implementation left in 3.3, but 3.2 still has th

[issue12656] test.test_asyncore: add tests for AF_INET6 and AF_UNIX sockets

New submission from Charles-François Natali : As noted in issue #12502, test_asyncore only tests AF_INET sockets. With the patch attached, the vast majority of the tests will also be run with AF_UNIX and AF_INET6 sockets (if supported by the host OS). -- components: Tests files

[issue12464] tempfile.TemporaryDirectory.cleanup follows symbolic links

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

[issue12655] Expose sched.h functions

Charles-François Natali added the comment: I'm +0. It would certainly be fun, but I'm not so sure about the "profit" part. The main usage of the scheduler API is for real-time policies, and I somehow doubt Python is commonly used in this area (but I could be wrong). F

[issue12655] Expose sched.h functions

Charles-François Natali added the comment: > I actually implemented this because I wanted to confine a Python process to a > cpu to prevent keep it from being tossed from core to core. It made sense to > bring the other scheduling functions along for the ride. Why didn't you

[issue12656] test.test_asyncore: add tests for AF_INET6 and AF_UNIX sockets

Changes by Charles-François Natali : Added file: http://bugs.python.org/file22802/test_ayncore.diff ___ Python tracker <http://bugs.python.org/issue12656> ___ ___ Pytho

[issue12656] test.test_asyncore: add tests for AF_INET6 and AF_UNIX sockets

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

[issue12760] Add create mode to open()

Charles-François Natali added the comment: See also issue 12105. A couple downsides: - O_EXCL is not necessarily portable (doesn't work well with NFS, maybe not on Windows?) - O_EXCL is useful, as is O_CLOEXEC: to be consistent, we should also end up adding all other commonly-used

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

Charles-François Natali added the comment: 2011/8/16 Dave Malcolm : > So in this case, "sys.platform"'s final digit is reporting the major release > of the kernel running outside the chroot-ed build environment (ironically > bearing even less relationship to that

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

Charles-François Natali added the comment: > My question too!  I would say that stable releases should probably not get > this change, but should force sys.platform to linux2 on 3.x kernels. > The point is precisely that we don't change anything: applications checking against sy

[issue12760] Add create mode to open()

Charles-François Natali added the comment: > The "#ifdef O_EXCL" in the source code is probably very old. Copying a > message I posted on python-ideas: > > O_EXCL is a POSIX standard. It is also supported > under Windows by the _open/_wopen compatibility functions (wh

[issue12775] immense performance problems related to the garbage collector

Charles-François Natali added the comment: There's been some work done on the GC some time ago to address this type of pattern (I think to reduce from quadratic complexity to amortized linear complexity). I'm adding Antoine and Martin who were involved in this. > Here is a

[issue12760] Add create mode to open()

Charles-François Natali added the comment: > Yeah, but I think "exclusively" is quite misleading since it does not > perform any locking of any kind. It might be misleading, but I find it clear enough, and this name has been endorsed by POSIX. Furthermore, there's an

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

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

[issue12650] Subprocess leaks fd upon kill()

Charles-François Natali added the comment: Patch committed. This should also fix the original problem. Gabriele, thanks for the report. -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python track

[issue12650] Subprocess leaks fd upon kill()

Charles-François Natali added the comment: Reopening. The new tests are failing on solaris and Debian parallel buildbots: http://www.python.org/dev/buildbot/all/builders/x86 debian parallel 3.x/builds/2734/steps/test/logs/stdio http://www.python.org/dev/buildbot/all/builders/sparc solaris10

[issue12650] Subprocess leaks fd upon kill()

Charles-François Natali added the comment: > This means that the child process didn't get reaped by _cleanup(). The most likely cause is that when _cleanup() calls waitpid(pid, WNOHANG), the child process hasn't exited yet. Since I had already set a rather high timeout to avoid

[issue12650] Subprocess leaks fd upon kill()

Charles-François Natali added the comment: The test now passes on the buildbots, closing. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issu

[issue12783] test_posix failure on FreeBSD 6.4: test_get_and_set_scheduler_and_param

New submission from Charles-François Natali : http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%206.4%203.x/builds/1734/steps/test/logs/stdio """ == ERROR: test_get_and_set_sche

[issue12786] subprocess wait() hangs when stdin is closed

Charles-François Natali added the comment: Hello Idan, > The following program hangs on Debian Debian is a good choice :-) Concerning your example, it hangs is because the file descriptor used to communicate with proc1 is inherited when proc2 is created (FDs are inherited upon fork

[issue12786] subprocess wait() hangs when stdin is closed

Charles-François Natali added the comment: Here's a patch + test for 2.7. > Really? This is on gentoo, not debian, admittedly: That's because the change of close_fds to True by default and the CLOEXEC flag were added in 3.2. Since 3.1 is in security-fix mode only, this patch is

[issue12783] test_posix failure on FreeBSD 6.4: test_get_and_set_scheduler_and_param

Charles-François Natali added the comment: Here's a patch skipping this part of the test on FreeBSD (it actually also fails on FreeBSD 7.2). Note that while calling sched_setparam(param) results in EINVAL with SCHED_OTHER processes, calling sched_setscheduler(SCHED_OTHER, param) works

[issue11657] multiprocessing_{send,recv}fd fail with fds > 256

Charles-François Natali added the comment: > I looked at multiprocessing code, but didn't understand how to trigger a > call to these functions. Makes it hard to come up with a unit test... Here's a sample test: """ import _multiprocessing import os import

[issue12783] test_posix failure on FreeBSD 6.4: test_get_and_set_scheduler_and_param

Charles-François Natali added the comment: The test now passes on FreeBSD buildbots. Closing. -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.or

[issue11657] multiprocessing_{send,recv}fd fail with fds > 256

Charles-François Natali added the comment: > Charles; you have +commit, it seems. Yeah, I could of course do this myself, but since Petri already submitted a patch and seemed to be willing to update it with a test, I thought he might be interested in this (I've also seen he's par

[issue6560] socket sendmsg(), recvmsg() methods

Charles-François Natali added the comment: > New changeset c64216addd7f by Nick Coghlan in branch 'default': > Add support for the send/recvmsg API to the socket module. Patch by David > Watson and Heiko Wundram. (Closes #6560) > http://hg.python.org/cpython/rev/c64216ad

[issue11657] multiprocessing_{send,recv}fd fail with fds > 256

Charles-François Natali added the comment: > I'm fine if you fix it, as I'm currently really short on time myself. OK, I'll go ahead. > For 3.3, it may be relevant that send/recvmsg are now available via the > socket API (see #6560). Indeed. We might still need C c

[issue12821] test_fcntl failed on OpenBSD 5.x

Charles-François Natali added the comment: Note that it's been fixed in default with the recent sys.platform refactoring: 26 if (sys.platform.startswith(('netbsd', 'freebsd', 'openbsd', 'bsdos')) 27 or sys.platform == 'dar

[issue6560] socket sendmsg(), recvmsg() methods

Charles-François Natali added the comment: > However, in doing this, I noticed that these methods will, at best, work > during the time between connection and the socket going secure and were not > added to the list of methods that the SSL is documented as exposing. Perhaps > we

[issue12827] OS-specific location in Lib/tempfile.py for OpenBSD

Charles-François Natali added the comment: > /usr/tmp is not (used) on OpenBSD. How is that a problem? Those are just possible temporary directories to try, so if it doesn't exist, it won't be used (typically ENOENT will be catched when opening a tmpfile). Also, since it's l

[issue12827] OS-specific location in Lib/tempfile.py for OpenBSD

Charles-François Natali added the comment: > Because it's not exactly a bug, can you only apply the patch to Python 3.3? Well, we could, but: - it doesn't fix a bug - it doesn't bring any obvious benefit (performance, security, etc) - it introduces an OS-specific case for n

[issue12827] OS-specific location in Lib/tempfile.py for OpenBSD

Charles-François Natali added the comment: > We can keep this patch in our tree, I understand your position. I could be missing something, but why do you have this patch in the first place? If it turns out to be useful, then it's of course better to include it upstream, I just don&#x

[issue12827] OS-specific location in Lib/tempfile.py for OpenBSD

Charles-François Natali added the comment: > it seems that this patch could be safely removed from our port tree. Alright, I'm closing then. > Thanks for all information. And thanks for your help and bug reports concerning OpenBSD-specific issues! -- resolution: ->

[issue12821] test_fcntl failed on OpenBSD 5.x

Charles-François Natali added the comment: Committed to 3.2 and 2.7. Rémi, thanks for the report. -- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.or

[issue12822] NewGIL should use CLOCK_MONOTONIC if possible.

Charles-François Natali added the comment: > Using CLOCK_MONOTONIC is better than CLOCK_REALTIME (default) for GIL > because settimeofday() may break the pthread_cond_timedwait(). Indeed. A couple remarks: - regular locks and conditions variables exposed by the threading module suffer

[issue12810] Remove check for negative unsigned value in socketmodule.c

Charles-François Natali added the comment: Thanks. I'll commit this patch tomorrow. I noticed you didn't indicate your full name: do you mind being listed in Misc/ACKS? -- components: +Extension Modules keywords: +easy nosy: +neologix stage: -> commit review type:

[issue6560] socket sendmsg(), recvmsg() methods

Charles-François Natali added the comment: Here's a patch skipping testFDPassSeparate and testFDPassSeparateMinSpace on OS X < 10.5, due to known kernel bugs (see http://developer.apple.com/library/mac/#qa/qa1541/_index.html). For InterruptedSendTimeoutTest and testInterruptedSendmsgTim

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