Roundup Robot added the comment:
New changeset e2b234f5bf7d by Antoine Pitrou in branch 'default':
Issue #16105: When a signal handler fails to write to the file descriptor
registered with ``signal.set_wakeup_fd()``, report an exception instead of
ignoring the error.
Antoine Pitrou added the comment:
Ok, I pushed the patch to 3.4. Thanks for the report!
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16105
Antoine Pitrou added the comment:
Updated patch using PyErr_WriteUnraisable().
--
stage: - patch review
Added file: http://bugs.python.org/file31325/wakeup_fd_error2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16105
Felipe Cruz added the comment:
Looks good.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16105
___
___
Python-bugs-list mailing list
Antoine Pitrou added the comment:
Here is a cleaned up patch.
However, I'm wondering if raising an error is a good idea. The effect will be
to get cryptic OSErrors at random execution points. Perhaps using
PyErr_WriteUnraisable would be better?
--
versions: -Python 2.6, Python 2.7,
Felipe Cruz added the comment:
Looks like PyErr_WriteUnraisable can be a better choice. Exceptions at random
execution points looks a little bit dirty at least for this case.
--
___
Python tracker rep...@bugs.python.org
Felipe Cruz added the comment:
I've followed latest suggestions.
Test and code updated.
--
Added file: http://bugs.python.org/file27598/issue16105_v4.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16105
Charles-François Natali added the comment:
You mean retry one time or until success?
Until success.
It should also come with a test.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16105
Felipe Cruz added the comment:
This patch retries write() until success if errno == EINTR.
There is also a test.
--
Added file: http://bugs.python.org/file27428/issue16105_v3.patch
___
Python tracker rep...@bugs.python.org
STINNER Victor added the comment:
A signal handler can be called anymore, anywhere. How do you handle such
exception in an application? handle: do something better than exit the
apllication.
--
___
Python tracker rep...@bugs.python.org
STINNER Victor added the comment:
A signal handler can be called anymore, anywhere.
Oopos: anywhere/anytime.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16105
___
Charles-François Natali added the comment:
A signal handler can be called anymore, anywhere. How do you handle such
exception in an application? handle: do something better than exit the
apllication.
Well, chances are you won't, but failing with an explicit error
message is better than
Felipe Cruz added the comment:
Why limit to EBADF? You could also have EPIPE, EINVAL and many other errors.
The only error you may not want to report is EAGAIN.
Charles,
You're right! If all errno cases get covered in the patch, will It looks
reasonable?
--
Charles-François Natali added the comment:
Why limit to EBADF? You could also have EPIPE, EINVAL and many other errors.
The only error you may not want to report is EAGAIN.
Charles,
You're right! If all errno cases get covered in the patch, will It looks
reasonable?
Raising an error in
Felipe Cruz added the comment:
Raising an error in case the signal can't be written to the FD
(because the other end didn't drain the pipe/socket) seems reasonable.
You should just retry on EINTR (although any sane implementation
shouldn't return EINTR on non-blocking write, I don't think
Charles-François Natali added the comment:
I would not say that is a bug, but there is a write(wakeup_fd) call
with ignored return code and maybe this can be improved to an output
to stderr, or maybe a better solution.
The problem is that it's called from the signal handler, so there's not
Antoine Pitrou added the comment:
The problem is that it's called from the signal handler, so there's not
much we can do here (and certainly not log a warning or raise an
exception).
However, I think the errno could be passed via the void * argument to
Py_AddPendingCall. Then
Felipe Cruz added the comment:
Hello,
since Antonie mentioned Py_AddPendingCall I came up with a patch describing
what he proposed.
Let me know if this patch can be improved or discarded(if the problem requires
a more sophisticated solution). In case of improvement I can also submit
another
Charles-François Natali added the comment:
since Antonie mentioned Py_AddPendingCall I came up with a patch describing
what he proposed.
Let me know if this patch can be improved or discarded(if the problem
requires a more sophisticated solution). In case of improvement I can also
Charles-François Natali added the comment:
I agree with Felipe that issues here can be difficult to diagnose. For
example the fd could get mistakingly closed, but the write() EBADF would then
be ignored and the expected signal wakeups would be lost.
Yeah, but it's also completely possible
New submission from Felipe Cruz:
It's possible to set a read only FD to signal.set_wakeup_fd(fd)
Since write call[1] inside 'trip_signal' return code is ignored, no error will
be raised.
An untested solution is to call fcntl in this FD to check presence of write
flags.
1 -
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16105
___
___
Python-bugs-list
STINNER Victor added the comment:
Is it really a bug? A file descriptor is just an integer, it may be replaced
later. Passed fd may be writable when set_wakeup_fd() is called, but then
become read-only.
--
___
Python tracker rep...@bugs.python.org
Felipe Cruz added the comment:
I would not say that is a bug, but there is a write(wakeup_fd) call with
ignored return code and maybe this can be improved to an output to stderr, or
maybe a better solution.
--
___
Python tracker
24 matches
Mail list logo
