STINNER Victor added the comment:
Guido wrote:
This still leaves case (1), where the FD is already bad when we register it.
I am actually fine with sometimes raising and sometimes not; I don't want to
pay the extra overhead of doing an fstat() or some other syscall just to verify
that it is
STINNER Victor added the comment:
To find an invalid FD when select() fails with EBAD, we can use something
like:
http://ufwi.org/projects/nufw/repository/revisions/b4f66edc5d4dc837f75857f8bffe9015454fdebc/entry/src/nuauth/tls_nufw.c#L408
Oh, the link is dead. Copy/paste of the code:
---
/*
Changes by STINNER Victor victor.stin...@gmail.com:
--
components: +asyncio
nosy: +yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19017
___
STINNER Victor added the comment:
What is the status of this issue?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19017
___
___
STINNER Victor added the comment:
The issue #19876 has been closed.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19017
___
___
STINNER Victor added the comment:
What is the status of this issue?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19017
___
___
Charles-François Natali added the comment:
What is the status of this issue?
AFAICT, we haven't reached a consensus yet on the best way to handle EBADF.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19017
Guido van Rossum added the comment:
AFAICT, we haven't reached a consensus yet on the best way to handle
EBADF.
By which you mean that you still don't agree with my proposal? Which is to
fix it for most syscalls but not for select(), poll() and similar (anything
that the new selectors module
Charles-François Natali added the comment:
By which you mean that you still don't agree with my proposal? Which is to
fix it for most syscalls but not for select(), poll() and similar (anything
that the new selectors module interfaces to).
I agree with your proposal, but that's another issue
Guido van Rossum added the comment:
Eww, sorry. That's the second time I mistook this thread for the other. I
re-read the original description and I now think that we should follow your
original advice.
There are two separate cases:
(1) Registering an invalid FD; this succeeds for
STINNER Victor added the comment:
To find an invalid FD when select() fails with EBAD, we can use something like:
http://ufwi.org/projects/nufw/repository/revisions/b4f66edc5d4dc837f75857f8bffe9015454fdebc/entry/src/nuauth/tls_nufw.c#L408
--
___
Guido van Rossum added the comment:
Charles-Francois, sorry to add you back to the bug, but (a) I thought you had
agreed to a compromise patch that restarts signals in most cases but not for
select(), poll() etc.; (b) I may have found a flaw in the idea.
The flaw (if it is one) is related to
Guido van Rossum added the comment:
Interesting issue. ISTM that closing the FD before unregistering it is a
programmer's mistake that shouldn't pass silently. And closing it in a
separate thread while the selector is active sounds like an even bigger bug.
Could we report an new event type
Guido van Rossum added the comment:
The problem is that for epoll (and kqueue I think) the FD is
automagically removed from the backend, which means that we won't get
any notification for this FD, hence we're unable to report it as
closed.
That makes it sound like it will be hard to respond
Charles-François Natali added the comment:
Interesting issue. ISTM that closing the FD before unregistering it is a
programmer's mistake that shouldn't pass silently. And closing it in a
separate thread while the selector is active sounds like an even bigger bug.
Agreed.
Could we
New submission from Charles-François Natali:
Currently, in case of invalid file descriptor (which can happen easily e.g. if
the user closes the FD before unregistering it), selector.select() will react
differently depending on the backend:
SelectSelector fails with EBADF
PollSelector returns
Antoine Pitrou added the comment:
Another possibility would be to silently fix those, i.e. in case of
EBADF/POLLNVAL in select/poll, remove the offending FD from the list of
monitored FDs.
Or we could remove the fd *and* still raise an error the first time, or at
least a warning. It sounds
Charles-François Natali added the comment:
Or we could remove the fd *and* still raise an error the first time, or at
least a warning. It sounds like a programming error, so I'm not sure it's a
good idea to silence it.
Yeah, sure. By silently I meant without user intervention, sorry
for
Antoine Pitrou added the comment:
Now I'm not sure between raising an error or just logging it.
If logged, it should be a Warning rather than an actual logging call,
IMO.
--
___
Python tracker rep...@bugs.python.org
STINNER Victor added the comment:
Would it be possible to emit an event invalid fd with the fd? So the user
can decide what to do on such case: ignore, log, raise an exception, ...
--
___
Python tracker rep...@bugs.python.org
20 matches
Mail list logo
