Charles-François Natali added the comment:
Looks good to me.
--
nosy: +neologix
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/issu
Charles-François Natali added the comment:
> 2) http://sources.redhat.com/bugzilla/show_bug.cgi?id=12453
We actually had another issue due to this particular libc bug:
http://bugs.python.org/issue6059
Basically, the problem is that if some libraries are dynamically
loaded in an interlea
Charles-François Natali added the comment:
Oh, and BTW, for the "Backtrace stopped: frame did not save the PC", you might
want to install the libc-dbg package. This might help in finding precisely
where it's crashing.
--
___
Python
Charles-François Natali added the comment:
> I think I got it: pthread_setaffinity_np() does not crash.
Nice.
Out of curiosity, I just looked at the source code, and it just does
sched_setaffinity(thread->tid), so you can do the same with
sched_setaffinity(syscall(SYS_gettid)) f
Charles-François Natali added the comment:
> If we have access (and as I understood from Victor's post we do):
> pthread_getaffinity_np() also exists on FreeBSD, which would be
> an advantage.
Yes, but I see several drawbacks:
- as noted by Victor, it's really easy to crash
Charles-François Natali added the comment:
> Do you mean that signal.pthread_kill() should be removed? This function is
> very useful and solve some issues that cannot be solved differently. At the
> same time, I don't think that it's possible to workaround the crashes. A
Changes by Charles-François Natali :
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue12975>
___
___
Pyth
Changes by Charles-François Natali :
Removed file: http://bugs.python.org/file23150/unnamed
___
Python tracker
<http://bugs.python.org/issue12975>
___
___
Python-bug
Charles-François Natali added the comment:
> According to the following article, a fsync is also needed on the
> directory after a rename. I don't understand if is it always needed for
> an atomic rename, or if we only need it for the "atomic write" pattern.
It'
Charles-François Natali added the comment:
> I'd prefer to disable the misbehaving functions entirely on arm.
-10
If we start disabling features on platforms with partly bogus implementations,
we might as well drop threading on OpenBSD, sendmsg() on OS-X, etc.
Furthermore, it'
Charles-François Natali added the comment:
Hello,
According to http://fxr.watson.org/fxr/ident?v=NETBSD;im=3;i=EVFILT_TIMER
EVFILT_TIMER is defined on NetBSD.
As for MirBSD, with all due respect, it really looks like a niche platform,
definitely not officially supported by Python.
Of course
Charles-François Natali added the comment:
Since this patch alone won't be enough to support MirBSD (and is required only
for MirBSD), I suggest you to post the complete patch, and rename this issue
"add support for MirBSD platform", or something along those lines.
That way,
New submission from Charles-François Natali :
Now that sendmsg()/recvmsg() are exposed in socketmodule, we could use them to
replace the ad-hoc FD-passing routines used by multiprocessing.reduction.
Antoine suggested adding sendfd()/recvfd() methods to socket objects, but I'm
not sure
Charles-François Natali added the comment:
> I don't think that it's a problem to remove private functions.
>
Alright.
> Is it mandatory to send a non-empty message (first argument for sendmsg, b'x'
> in your patch)? The original C function sends a random byt
Changes by Charles-François Natali :
Added file: http://bugs.python.org/file23166/multiprocessing_fd-1.diff
___
Python tracker
<http://bugs.python.org/issue12981>
___
___
Changes by Charles-François Natali :
Removed file: http://bugs.python.org/file23156/multiprocessing_fd.diff
___
Python tracker
<http://bugs.python.org/issue12981>
___
___
Charles-François Natali added the comment:
I only tried on Linux.
By the way, what's the simplest way to create a personal clone to test patches
on some of the buildbots before committing them?
--
___
Python tracker
<http://bugs.py
Charles-François Natali added the comment:
It's a dupe of issue #8426: the Queue isn't full, but the underlying pipe is,
so the feeder thread blocks on the write to the pipe (actually when trying to
acquire the lock protecting the pipe from concurrent access).
Since the children
New submission from Charles-François Natali :
Since the rewrite in pure Python of multiprocessing.Connection (issue #11743),
multiprocessing.Connection sends and receives the length of the data (used as
header) in host byte order.
This will break if the connection's endpoints are on ma
Changes by Charles-François Natali :
--
nosy: haypo, neologix
priority: normal
severity: normal
stage: needs patch
status: open
title: _XOPEN_SOURCE usage on Solaris
type: behavior
versions: Python 3.3
___
Python tracker
<http://bugs.python.
New submission from Charles-François Natali :
While testing issue #12981, I stumbled on a problem on OpenIndiana buildbot:
"""
test test_multiprocessing crashed -- Traceback (most recent call last):
File
"/export/home/buildbot/64bits/custom.cea-indiana-amd64/build/Lib/test
Charles-François Natali added the comment:
> Did you try it on Linux, FreeBSD and/or Windows?
It works fine on Linux, FreeBSD, OS X and Windows, but not on Solaris: see
issue #12999.
--
dependencies: +_XOPEN_SOURCE usage on Solaris
___
Pyt
Charles-François Natali added the comment:
Hello Benny,
> As requested, here is the full patch for MirBSD support. The diff was taken
> against version 2.7.2. It is really quite easy, you just need to handle
> MirBSD like OpenBSD.
> With this patch, I can successfully compile an
Charles-François Natali added the comment:
Here's a patch taking into account the fact that
multiprocessing.reduction might not be available and importing it can
raise an ImportError (which is already the case with the C
implementation, but multiprocessing.reduction tests have been
Changes by Charles-François Natali :
Removed file: http://bugs.python.org/file23166/multiprocessing_fd-1.diff
___
Python tracker
<http://bugs.python.org/issue12
New submission from Charles-François Natali :
http://www.python.org/dev/buildbot/all/builders/x86 FreeBSD 7.2
3.x/builds/2129/steps/test/logs/stdio
"""
==
FAIL: testRecvmsgTrunc (test.test_socket
Charles-François Natali added the comment:
> "Since the rewrite in pure Python of multiprocessing.Connection (issue
> #11743), multiprocessing.Connection sends and receives the length of the data
> (used as header) in host byte order."
>
> I don't think so,
Charles-François Natali added the comment:
> "It works fine on Linux, FreeBSD, OS X and Windows, but not on Solaris: see
> issue #12999."
>
> Oh, thank for testing before committing :) It's hard to debug multiprocessing.
Yes. Especially when you stumble upon a kern
Changes by Charles-François Natali :
Removed file: http://bugs.python.org/file23180/multiprocessing_fd-2.diff
___
Python tracker
<http://bugs.python.org/issue12
Charles-François Natali added the comment:
> I had a look at this patch, and the FD passing looked OK, except
> that calculating the buffer size with CMSG_SPACE() may allow more
> than one file descriptor to be received, with the extra one going
> unnoticed - it should use CMSG_L
Changes by Charles-François Natali :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Charles-François Natali added the comment:
I committed the patch to catch the ImportError in test_multiprocessing.
I'll commit the other patch (pure Python version) in a couple days.
> Ah, no, you're right - that's fine. Sorry for the false alarm.
No problem. As they say,
Charles-François Natali added the comment:
> The patch includes a test case, but like the other recently-added
> tests for the function, it isn't guarded against
> multiprocessing.reduction being unavailable. Issue #12981 has a
> patch "skip_reduction.diff" (already
Charles-François Natali added the comment:
Here's an updated patch, with more tests.
Please review!
--
keywords: +needs review
nosy: +haypo
stage: patch review -> commit review
Added file: http://bugs.python.org/file23225/socketcan_
Charles-François Natali added the comment:
> - dummy question: why an address is a tuple with 1 string instead of just
> the string? Does AF_UNIX also uses a tuple of 1 string?
I think the reason behind the tuple is future proofing.
Here's the definition of `struct sockaddr_can`
Changes by Charles-François Natali :
Removed file: http://bugs.python.org/file23225/socketcan_v4.patch
___
Python tracker
<http://bugs.python.org/issue10141>
___
___
Pytho
Changes by Charles-François Natali :
--
dependencies: -_XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED usage on Solaris
resolution: -> fixed
stage: -> committed/rejected
___
Python tracker
<http://bugs.python.org/i
Changes by Charles-François Natali :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue12981>
___
___
Python-bugs-list mailing list
Un
Charles-François Natali added the comment:
Patch applied, thanks!
--
nosy: +neologix
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.4
___
Python track
Charles-François Natali added the comment:
Confirmed with default.
The problem is that the TextIOWrapper gets collected after the underlying
BufferedRWPair has been cleared (tp_clear) by the garbage collector: when
_PyIOBase_finalize() is called for the TextIOWrapper, it checks if the textio
Charles-François Natali added the comment:
With test.
--
Added file: http://bugs.python.org/file23278/buffered_closed_gc-1.diff
___
Python tracker
<http://bugs.python.org/issue13
Changes by Charles-François Natali :
Removed file: http://bugs.python.org/file23277/buffered_closed_gc.diff
___
Python tracker
<http://bugs.python.org/issue13070>
___
___
Changes by Charles-François Natali :
Removed file: http://bugs.python.org/file23278/buffered_closed_gc-1.diff
___
Python tracker
<http://bugs.python.org/issue13
Changes by Charles-François Natali :
Added file: http://bugs.python.org/file23279/buffered_closed_gc-1.diff
___
Python tracker
<http://bugs.python.org/issue13070>
___
___
Charles-François Natali added the comment:
See http://bugs.python.org/issue12469, specifically
http://bugs.python.org/issue12469#msg139831
"""
> > When signals are unblocked, pending signal ared delivered in the reverse
> > order
> > of their number (als
Changes by Charles-François Natali :
--
keywords: +patch
Added file: http://bugs.python.org/file23284/check_signum_order.diff
___
Python tracker
<http://bugs.python.org/issue13
Charles-François Natali added the comment:
> Shouldn't the test use "self.BufferedRWPair" instead of
> "io.BufferedRWPair"?
Yes.
> Also, is it ok to just return NULL or should the error state also be
> set?
Well, I'm not sure, that why I made you and
Changes by Charles-François Natali :
Removed file: http://bugs.python.org/file23279/buffered_closed_gc-1.diff
___
Python tracker
<http://bugs.python.org/issue13
Charles-François Natali added the comment:
> @requires_freebsd_version should be factorized with
> @requires_linux_version.
Patches attached.
> Can we workaround FreeBSD (< 8) bug in C/Python?
Not really.
> Or should we remove the function on FreeBSD < 8?
There's
Charles-François Natali added the comment:
So, Victor, what do you think of the last version?
This patch has been lingering for quite some time, and it's really a
cool feature.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Charles-François Natali :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Charles-François Natali added the comment:
Hello,
method:: socket.getsockopt(level, optname[, optarg])
The overloading of the third parameter is confusing: it can already be an
integer value or a buffer size, I don't think that adding a third possibility
is a good idea. It might be b
Changes by Charles-François Natali :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Charles-François Natali added the comment:
test_multiprocessing frequently hangs on FreeBSD < 8 buildbots, and this
probably has to do with the limit on the max number of POSIX semaphores:
"""
==
ERRO
Charles-François Natali added the comment:
> Probably. OTOH, not setting the error state when returning NULL is
> usually an error (and can result in difficult-to-debug problems), so
> let's stay on the safe side.
> RuntimeError perhaps.
OK, I'll update the patch acc
Charles-François Natali added the comment:
-1
IMHO, implementing SysV semaphores would be a step backwards, plus the API is a
real pain.
I think there's no reason to complicate the code to accomodate such corner
cases, especially since the systems that don't support POSIX semap
Charles-François Natali added the comment:
Sorry, forgot about this issue...
Updated patch (I'm not really satisfied with the error message, don't
hesitate if you can think of a better wording).
--
Added file: http://bugs.python.org/file23319/buffered_closed
Charles-François Natali added the comment:
> I've attached an update for the previous patch. Now there's no more
> overloading for the third argument and socket.getsockopt accepts one more
> optional argument -- a buffer to use as an input to kernel.
Remarks:
""
Changes by Charles-François Natali :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue10141>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Charles-François Natali :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Charles-François Natali added the comment:
> I don't have much to say about the patch, given that I don't know
> anything about CAN and my system doesn't appear to have a "vcan0"
> interface.
I had never heard about it before this issue, but the protocol is
Charles-François Natali added the comment:
Committed to 3.2 and default.
Victor, thanks for the report!
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Charles-François Natali added the comment:
> The issue doesn't affect Python 2.7?
>
Duh!
I was sure the _io module had been introduced in Python 3 (I/O layer
rewrite, etc).
Yes, it does apply to 2.7. I'll commit the patch later today.
--
__
Charles-François Natali added the comment:
Committed.
Matthias, Tiago, thanks!
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Charles-François Natali added the comment:
> Modifying an object which is already on a traditional queue can also
> change what is received by the other thread (depending on timing).
> So Queue.Queue's put() is not "atomic" either. Therefore I do not
> believe this
Charles-François Natali added the comment:
>From python-dev:
"""
I work on Ubuntu Jaunty for my cpython development work - an old version, I
know, but still quite serviceable and has worked well for me over many months.
With the latest default cpython repository, howeve
Charles-François Natali added the comment:
> which would imply that on this system at least, the AF_CAN definition is
> supposed to come from elsewhere.
Yes, from .
Looks like a crappy libc version: is present, but AF_CAN is not
defined.
Just for fun, is PF_CAN defined?
You might t
Charles-François Natali added the comment:
Here's a better patch.
It only touches socketmodule.c, so no need for autoconf, just use make.
If it works on your box, I'll test it on the custom buildbots before pushing it
for good (if I learned one thing, it's to never underestimat
Charles-François Natali added the comment:
Hello,
> Did anyone test this fix for case of fork() being called from Python sub
> interpreter?
>
Not specifically, unless it's part of the test suite.
Anyway, unless this problem is systematic - which I doubt - it
probably wouldn
Charles-François Natali added the comment:
Working fine on the buildbots and Vinay's box, closing!
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.pyth
Charles-François Natali added the comment:
> Attached patch reads the name of the server socket instead of using
> HOST or 'localhost'.
> By the way, why do we use 'localhost' instead of '127.0.0.1' for
> support.HOST? '127.0.0.1' d
Charles-François Natali added the comment:
> The condition contradicts the exception text:
Why?
The offset is zero-based, so 0 <= offset < size is a valid check.
> First of all, it doesn't fail (at least on Linux), I tested it before
> posting.
Hmmm.
You got lucky, sinc
Charles-François Natali added the comment:
I did a quick test (calling fork() from a subinterpreter), and as
expected, I couldn't reproduce the problem.
So I still favor an OOM condition making pthread_setspecific bail out
with ENOMEM, othe other option being a nasty libc bug.
If the pr
Changes by Charles-François Natali :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue13156>
___
___
Python-bugs-list mailing list
Unsubscribe:
Charles-François Natali added the comment:
Note that this doesn't apply to default: the problem is that 2.7 and 3.2 don't
use native TLS, and with the ad-hoc TLS implementation, a NULL value isn't
supported:
"""
/* Internal helper.
* If the current thr
Charles-François Natali added the comment:
> So, the documentation you quote is only to do with the main
> interpreter and is not how things work for sub interpreters.
You're right, my bad.
However, it would probably be better to destroy/reset the autoTLSkey
even if the current thr
Charles-François Natali added the comment:
> So the solution would be simply to backout this patch on 2.7 and 3.2.
Actually, I just checked, and the native TLS implementation is present in 3.2,
so this problem shouldn't show up: did you test it with 3.2?
AFAICT, this should only af
Charles-François Natali added the comment:
> Here is a patch for import.c.
Looks good to me.
> This new patch also fixes importlib.
"""
path_tmp = path + '.tmp'
with _io.FileIO(path_tmp, 'wb') as
Charles-François Natali added the comment:
Here's a patch for 3.2 and default which calls
PyThread_set_key_value() only if there was an auto thread state
previously associated (while the current code works with pthread TLS,
there are other implementations which may behave strangely, and
th
Charles-François Natali added the comment:
> Or perhaps append the PID to the name of the temp file ?
> (easier done in Python than in C :-))
I don't really like appending PIDs to generate file names:
- if you have multiple processes at the same time, they'll all write
thei
Charles-François Natali added the comment:
> Related : #1565071 and #3990 . There is no reason to keep plat-xxx files if
> cannot be managed properly.
+1
--
___
Python tracker
<http://bugs.python.org/i
Charles-François Natali added the comment:
Note that I'm really +10 on this issue: such constants belong to individual
modules rather than to the unmanageable Lib/plat-XXX/.
--
nosy: +neologix
___
Python tracker
<http://bugs.python.org/is
Charles-François Natali added the comment:
Here's an updated patch.
I'll open a separate issue for the thread-safety.
--
keywords: +needs review
nosy: +pitrou
stage: -> patch review
Added file: http://bugs.python.org/file23489/pool_lifetime
Changes by Charles-François Natali :
Removed file: http://bugs.python.org/file21644/pool_lifetime_close.diff
___
Python tracker
<http://bugs.python.org/issue10
Charles-François Natali added the comment:
"""
"""Start a new thread to process the request."""
t = threading.Thread(target = self.process_request_thread,
args = (request, client_address))
if sel
Charles-François Natali added the comment:
The recent issue #13146 renewed my interest, so I'd like to make this move
forward, since I think an atomic rename/write API could be quite useful.
Issue #8604 (Adding an atomic FS write API) can be achieved relatively easily
with the typical (
Charles-François Natali added the comment:
> I would prefer to preserve the inheritance by default, and to change the
> daemonic attribute only if it is explicitly set to True or False.
> This way it will be backward compatible.
It may be backward compatible, but IMHO, the current be
Charles-François Natali added the comment:
> MoveFileTransacted is only available under Vista or later. You should be able
> to use MoveFileEx for the same effect.
Nice.
> "The solution? Let's remember that metadata changes are atomic. Rename is
> such a case."
Charles-François Natali added the comment:
> While a 20 second timeout may make sense for *unresponsive* servers,
> ECONNREFUSED probably indicates that the server is not listening on this
> port, so
> hammering it with 1,999 more connection attempts isn't going to help.
Charles-François Natali added the comment:
James, thanks for the report!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Charles-François Natali added the comment:
> I think there is a value to use the very same function names in the
> posix module as in the posix API.
It would still be the case, except that they'd live in distinct submodule.
> The posix API (and C in general) is also flat, and u
Charles-François Natali added the comment:
> I would prefer to keep the shared prefix even if we move functions to a new
> module. Python refers usually to the C documentation for the details of a
> function. If we rename a function, it becomes more difficult to get the
> m
Charles-François Natali added the comment:
Did you try with the current branches?
AFAICT, this should have been solved by 208a5290fd38 (issue #11265), and I did
a quick test with default and it seems to be fixed.
In any case, it's probably a good idea to add this test to test_asyncore.
Charles-François Natali added the comment:
>> Did you try with the current branches?
>
> Yes, the test is pass against the current default and 2.7 branches.
> One must remove EPIPE from the asyncore._DISCONNECTED frozenset to
> make the test to fail.
OK. Then I&#
Charles-François Natali added the comment:
> So it's impossible to reliably save and restore signal handlers through
> python when they can also be changed outside the python interpreter.
signal.getsignal() or signal.signal() return the current/previous handler as a
Python fu
Charles-François Natali added the comment:
The test fails on OS X:
"""
==
ERROR: test_handle_close_after_conn_broken
(test.test_asyncore.Test
Charles-François Natali added the comment:
> The test fails when use_poll is True.
> The difference between using poll() and poll2():
poll uses select(2), while poll2 uses poll(2) (duh, that's confusing).
It seems that on OS X Snow Leopard, poll(2) sets the POLLPRI flag upon
Charles-François Natali added the comment:
Rémi, do you want to submit a patch to skip those tests on OpenBSD?
--
___
Python tracker
<http://bugs.python.org/issue12
Charles-François Natali added the comment:
> Thanks. Although, on second thought, I'm not sure whether Amaury's
> idea (allowing a custom opener) is not better... Thoughts?
+1.
This would also address issues #12760 and #12105.
--
__
Changes by Charles-François Natali :
--
status: open -> closed
superseder: -> io.FileIO and io.open should support openat
___
Python tracker
<http://bugs.python.org/i
1 - 100 of 1826 matches
Mail list logo
