[issue1161031] Neverending warnings from asyncore
Changes by Brett Cannon br...@python.org: -- nosy: -brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1161031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1161031] Neverending warnings from asyncore
Aleksi Torhamo alexerion+pythonb...@gmail.com added the comment: Please correct me, if i'm wrong, but this seems to be a real bug, caused by people thinking that handle_expt is something like handle_error. As Tony stated, the docs say that handle_expt is called when out-of-band data arrives, and that is - i think - correct. poll, which uses select, calls _exception - handle_expt_event with fds from the third set of select. The manpage select_tut(2) has example code, which has a comment indicating that the third set is supposed to contain sockets with OOB data. poll2, however, calls readwrite, which calls handle_expt_event on error conditions. Furthermore, it calls handle_read_event on POLLPRI, which (according to the manpage of poll(2)) is supposed to indicate OOB data when using poll. Since handle_error is intended for python exceptions, currently there is no proper method to call on POLLERR and POLLNVAL, unless handle_close is called. With POLLNVAL, handle_close seems like the correct thing to do (manpage says it indicates that fd is not open.) With POLLERR, i have no idea. Manpage says Error condition, but from that, it's hard to say whether it refers to a temporary error condition or not. So, i think readwrite should look something like this: (Assuming POLLERR - handle_close, otherwise a new handler would probably have to be introduced) if flags select.POLLPRI: obj.handle_expt_event() if flags select.POLLIN: obj.handle_read_event() if flags select.POLLOUT: obj.handle_write_event() if flags (select.POLLERR | select.POLLNVAL | select.POLLHUP): obj.handle_close() -- nosy: +alexer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1161031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1161031] Neverending warnings from asyncore
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment: @Aleksy http://bugs.python.org/issue4501 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1161031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1161031] Neverending warnings from asyncore
Aleksi Torhamo alexerion+pythonb...@gmail.com added the comment: Sorry for the noise. I just registered, and started going through the open issues for asyncore in order. I'll read them all through before commenting on the next one.. I also bumped to this: http://groups.google.com/group/python-dev2/browse_thread/thread/eec1ddadefe09fd8/a38270231620870e?lnk=gstq=asyncore It seems lots of things i have been thinking about have already been done, but the whole asyncore is at a standstill. Any pointers on where i should look if i want to help with doing something to the current state of affairs? Thanks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1161031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1161031] Neverending warnings from asyncore
Brett Cannon br...@python.org added the comment: On Tue, Mar 31, 2009 at 06:39, Aleksi Torhamo rep...@bugs.python.orgwrote: Aleksi Torhamo alexerion+pythonb...@gmail.comalexerion%2bpythonb...@gmail.com added the comment: Sorry for the noise. I just registered, and started going through the open issues for asyncore in order. I'll read them all through before commenting on the next one.. I also bumped to this: http://groups.google.com/group/python-dev2/browse_thread/thread/eec1ddadefe09fd8/a38270231620870e?lnk=gstq=asyncore It seems lots of things i have been thinking about have already been done, but the whole asyncore is at a standstill. Any pointers on where i should look if i want to help with doing something to the current state of affairs? Thanks. Beyond looking at what is in trunk, nothing specific comes to mind. -- Added file: http://bugs.python.org/file13513/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1161031 ___brbrdiv class=gmail_quoteOn Tue, Mar 31, 2009 at 06:39, Aleksi Torhamo span dir=ltrlt;a href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt;/span wrote:brblockquote class=gmail_quote style=border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex; div class=imbr Aleksi Torhamo lt;a href=mailto:alexerion%2bpythonb...@gmail.com;alexerion+pythonb...@gmail.com/agt; added the comment:br br /divSorry for the noise.br br I just registered, and started going through the open issues forbr asyncore in order. I#39;ll read them all through before commenting on thebr next one..br br I also bumped to this:br a href=http://groups.google.com/group/python-dev2/browse_thread/thread/eec1ddadefe09fd8/a38270231620870e?lnk=gstamp;q=asyncore; target=_blankhttp://groups.google.com/group/python-dev2/browse_thread/thread/eec1ddadefe09fd8/a38270231620870e?lnk=gstamp;q=asyncore/abr br It seems lots of things i have been thinking about have already beenbr done, but the whole asyncore is at a standstill. Any pointers on where ibr should look if i want to help with doing something to the current statebr of affairs?br br Thanks./blockquotedivbrBeyond looking at what is in trunk, nothing specific comes to mind. br/div/divbr ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1161031] Neverending warnings from asyncore
Josiah Carlson josiahcarl...@users.sourceforge.net added the comment: Your analysis WRT handle_expt_event() is correct. I've been meaning to fix that for a while, but I forgot to do it in 2.6/3.0 with all of the other changes/fixes. Looking at the docs, you are also right about POLLNVAL. I also don't *know* what to do when presented with POLLERR, but few socket errors are transient (transient errors should be handled by the underlying stacks), so I agree with you that they should just be closed. I went ahead and made the changes as you have suggested, and also made the same change with the select-based loop. Errors on the socket just result in closing the socket, resulting in _exception() - close(). Thinking about it, I've also had a change of heart, and added a frozenset object called 'ignore_log_types', which specifies the log types to ignore. By default it is populated with 'warning', which squelches all currently existing unhandled * event bits. If you use self.log(arg) or self.log_info(one_arg), those lines are unchanged. Handle_error() uses the error type, which is also nice, but which you can also suppress with ease (though you really should be logging them so you can fix your code). I've attached a version that I think is pretty reasonable. Comments? Questions? -- keywords: +needs review, patch versions: +Python 2.7 -Python 2.6 Added file: http://bugs.python.org/file13516/async_no_warn.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1161031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1161031] Neverending warnings from asyncore
Aleksi Torhamo alexerion+pythonb...@gmail.com added the comment: The _exception() - close() change seems to be wrong. The third set of select() is supposed to represent oob data, so the previous use in the select-based loop should have been correct? Other than that, i can't see anything wrong with it. Maybe handle_expt_event should be reverted to the old one, that just calls handle_expt, too? The current version seems to assume that it is called on socket error conditions. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1161031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1161031] Neverending warnings from asyncore
Josiah Carlson josiahcarl...@users.sourceforge.net added the comment: You are right. Handling OOB data is within the exceptional condition that the select document specifies. I've added a check for error conditions within handle_expt_event(), which induces a handle_close() on discovery of an error, handle_expt() otherwise. One thing to consider is that when there is OOB data, and when handle_expt() isn't overridden, we will get churn because that data will never be read from the socket. I'm thinking about tossing a handle_close() as part of the default handle_expt() call. Attached is an updated patch without the handle_close() in handle_expt(). -- Added file: http://bugs.python.org/file13517/async_no_warn.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1161031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1161031] Neverending warnings from asyncore
Changes by Josiah Carlson josiahcarl...@users.sourceforge.net: Removed file: http://bugs.python.org/file13516/async_no_warn.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1161031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1161031] Neverending warnings from asyncore
Aleksi Torhamo alexerion+pythonb...@gmail.com added the comment: Ah, you're right. I hadn't thought about the exceptional condition being used to signal anything besides OOB. Looks really good to me. s/close/_exception/ in the select-based poll(), and i don't have anything more to add. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1161031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1161031] Neverending warnings from asyncore
Josiah Carlson josiahcarl...@users.sourceforge.net added the comment: Fixed the close() call and committed to trunk. Python 2.6 tests pass with the new version of the library. Calling it good :) . -- keywords: -needs review resolution: - accepted status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1161031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1161031] Neverending warnings from asyncore
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment: I still get some occasional EBADF failures when running pyftpdlib test suite by using poll(). I think that it makes more sense moving the: if flags (select.POLLHUP | select.POLLERR | select.POLLNVAL): obj.handle_close() ...lines at the top and return if handle_close() is called, as I did in the patch attached to issue 4501, which is: if flags (select.POLLHUP | select.POLLERR | select.POLLNVAL): obj.handle_close() else: if flags select.POLLIN: obj.handle_read_event() if flags select.POLLOUT: obj.handle_write_event() if flags select.POLLPRI: obj.handle_expt_event() -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1161031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1161031] Neverending warnings from asyncore
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment: ...after all no read/write methods should be called after the socket has been closed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1161031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1161031] Neverending warnings from asyncore
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment: If you're talking about r70904 then you did a different thing than the one I suggested. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1161031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1161031] Neverending warnings from asyncore
Tony Meyer anadelonb...@users.sourceforge.net added the comment: None of my arguments have really changed since 2.4. I still believe that this is a poor choice of default behaviour (and if it is meant to be overridden to be useable, then 'pass' or 'raise NotYetImplementedError' would be a better choice). However, my impression is that nothing I say will convince you of that, so I'll give up on that. It would have been interesting to hear from Andrew the reason for the code. However, this is definitely a documentation bug (as outlined previously), and so should be fixed, not closed. I can provide a patch if it stands a chance of being accepted. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1161031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1161031] Neverending warnings from asyncore
Gregory P. Smith g...@krypto.org added the comment: A documentation patch would be appreciated, thanks! -- nosy: +gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1161031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1161031] Neverending warnings from asyncore
Daniel Diniz aja...@gmail.com added the comment: Josiah: that'd be around rev36408, as 1.53 corresponds to rev36033 (from the log and issue 957240) -- nosy: +ajaksu2 stage: - test needed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1161031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1161031] Neverending warnings from asyncore
Josiah Carlson josiahcarl...@users.sourceforge.net added the comment: Considering that we're looking at 2.7 and 3.1, I think that (paraphrased) logging fallout from changes to 2.4 are a bit out-of- date. People who have continued to use asyncore/asynchat in the last 4 years have already changed their code. People who write new code already deal with the logging. Does anyone have a compelling reason as to why we shouldn't just close this bug? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1161031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1161031] Neverending warnings from asyncore
Changes by Daniel Diniz aja...@gmail.com: -- nosy: +brett.cannon type: - behavior versions: +Python 2.6 -Python 2.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1161031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1161031] Neverending warnings from asyncore
Changes by Giampaolo Rodola' [EMAIL PROTECTED]: -- nosy: +giampaolo.rodola ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1161031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1161031] Neverending warnings from asyncore
Changes by A.M. Kuchling: -- assignee: akuchling - josiahcarlson _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1161031 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
