Re^7: Does IO::Select work? (perfect)

[tye]

The bug report said that it happened, in one case, when he hit escape in the browser. So I doubt it was the kernel. It might not have been Perl or the script, either. It could be a non-kernel library. But the situation was described as and even sounds like it would be a situation where the script (which is what the programmer "has full control over") wasn't the software closing the socket. And the report says that there were other situations that caused the same problem.

That this violates your sensibilities is clear, but that seems poor justification for going on and on like this, just ignoring the evidence that contradicts that "the developer has full control over the lifespan of the socket". I agree that it is a bit unexpected and unfortunate that there are libraries of some kind that cause a socket to lose its file descriptor number.

But even if it turns out that it was a mistake on the part of the Perl script, then we just have a demonstration of it not being a trivial matter to find how the script is closing a socket unexpectedly. Debugging can be hard. I hope that isn't a surprise to you.

"In a perfect world" the programmer will have full control over the socket's fd's lifespan and will have no difficulty fixing when their control over the lifespan causes a fd to be closed other than the place where fds that are in the IO::Select object are managed. But we have clear evidence that the world isn't perfect.

The way IO::Select behaves in such a situation is terrible. It is trivial to fix it to at least complain when that situation happens. There is no excuse for silently doing stupid stuff in that situation, despite your many attempts to make excuses. It sounds like it isn't particularly hard to make it actually work well in that situation, so that fix should just be applied. This isn't a "just update the documentation" type of bug.

And in a perfect world, bugs in Perl and the kernel and all libraries will be fixed quickly and hardly anybody will be bothered by bugs so software doesn't need to take trivial steps to avoid silently doing stupid stuff when such a bug appears (especially when more than one case of such a bug was already reported in-the-wild).

[andal]

I agree that it is a bit unexpected and unfortunate that there are libraries of some kind that cause a socket to lose its file descriptor number.

I do understand, that there might be buggy libraries out there that close sockets, when they shouldn't. I also understand, that it is trivial matter to change behavior of IO::Select so, that it does not depend on presence of file descriptor. But at the end of the day, it is bug of those libraries, not bug of IO::Select. So it would be more appropriate to fix those libraries, not IO::Select.

What is good about fixing those things that are not really broken, and letting really broken stuff to function further? Personally I avoid using libraries that do unexpected stuff. They must die :)

[tye]

But at the end of the day, it is bug of those libraries, not bug of IO::Select.

No, it is a serious bug in IO::Select. At the end of a perfect day, it doesn't matter that IO::Select silently does stupid stuff for a case that one shouldn't end up in when in a perfect world. In the real world, there are lots of ways to easily end up in that case and so it is quite simply unacceptable for IO::Select to skip trivial work that would avoid silently doing stupid stuff in that common case.

[andal]

No, it is a serious bug in IO::Select. At the end of a perfect day, it doesn't matter that IO::Select silently does stupid stuff for a case that one shouldn't end up in when in a perfect world. In the real world, there are lots of ways to easily end up in that case and so it is quite simply unacceptable for IO::Select to skip trivial work that would avoid silently doing stupid stuff in that common case.

Well, I live in real world and in 10 years of network programming I haven't run up into situation where the behavior of IO::Select would be a problem for me. And so far neither you nor BrowserUK has provided practical example of such situation. Only theoretical.

Really, removing socket from IO::Select is the smallest thing that should be done before socket is closed. In practical life there's whole bunch of other stuff that should be done as well. For example: release data associated with the connection, notify the user that connection is closed (log it at least), possibly schedule establishment of new connection and so on. If you as developer are using some library that is not friendly enough to allow you to do all of this stuff, then you've made wrong choice for the library.

It is quite normal for 2 libraries to be incompatible, but it is strange and confusing when in this case one of the libraries is called "broken". Wouldn't "asking for new feature" be more appropriate here?