in reply to Re^7: Does IO::Select work? (perfect)
in thread Does IO::Select work? Anywhere?

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 :)

Replies are listed 'Best First'.
Re^9: Does IO::Select work? (perfect)
by tye (Sage) on Oct 24, 2012 at 13:14 UTC
    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.

    - tye        

[reply]
      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?

[reply]
        it is strange and confusing when in this case one of the libraries is called "broken".

        But it *IS* broken. Not because it doesn't remove a closed filehandle from the select set; but because it *SILENTLY* ignores the request to do so.

        As I said way back up there^, with added emphasis:

        Even a simple warning that you've made an attempt to remove a closed handle would help; but it isn't hard to fall back on a linear search of the array of file handles and relate their position in the array back to a fileno and hence bit vector bit.

        The API is remove() not removeOrDoNothing().

        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

        RIP Neil Armstrong
[reply]
[d/l]
[select]
        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.

        Actually, you are wrong again. None of those things have to happen before the socket is closed. Those are things that might (in theory) be desirable to do around the time that the socket is closed. None of them are things that are likely to just silently do nothing if the socket got closed before them (unless you implement them stupidly... like IO::Select).

        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.

        "would"? So, in theory, you don't think you'd have run into this problem. That's hilarious.

        - tye        

[reply]

In Section Seekers of Perl Wisdom