Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

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

by andal (Friar)
on Oct 24, 2012 at 08:13 UTC ( #1000567=note: print w/ replies, xml ) Need Help??


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


Comment on Re^8: Does IO::Select work? (perfect)
Re^9: Does IO::Select work? (perfect)
by tye (Cardinal) 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        

      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?

        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

        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        

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1000567]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (8)
As of 2014-07-28 04:53 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (186 votes), past polls