Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Re^6: Does IO::Select work? (Problem partially resolved)

by andal (Friar)
on Oct 23, 2012 at 14:36 UTC ( #1000485=note: print w/ replies, xml ) Need Help??


in reply to Re^5: Does IO::Select work? (Problem partially resolved)
in thread Does IO::Select work? Anywhere?

The mistake you keep making is assuming that it must be the (a) OS kernel that is doing this.

Well, it's not a mistake. If you remember, originally I've commented on your statement

because it is perfectly possible for a file handle to get closed without the program doing it explicitly
So we have the program and kernel. If you want to separate this into script, perl and kernel, then I'm ready to adjust my statement to be "perl won't close handle unless the script allows it". If you let the handle to go out of scope, then it means that you want it to be closed. If you didn't want it to be closed, then it is your mistake to let it go out of scope.

Well, it all becomes philosophical. I don't really care was it a bug in IO::Select or not. My main point was, the developer has full control over the life span of a socket. And if the developer looses some socket, then it is HIS error. Neither perl, nor kernel steal sockets from developer. If such thing happens, then it is a bug and it gets fixed as soon as it is discovered. But IO::Select has nothing to do with those bugs. So it was quite working and usable even when it was expecting that the socket is closed after it is removed from IO::Select. They just needed to put it into documentation. Nothing else.

And yes. If you get sockets messed up in threads, then it is either your error, or the error of threads support in perl. If it is in perl, then one should file bug report and hope for fix :)


Comment on Re^6: Does IO::Select work? (Problem partially resolved)
Re^7: Does IO::Select work? (Problem partially resolved)
by zentara (Archbishop) on Oct 23, 2012 at 14:41 UTC
    When you figure it out, they confine you on an island off the coast of hawaii. :-)

    I'm not really a human, but I play one on earth.
    Old Perl Programmer Haiku ................... flash japh
Re^7: Does IO::Select work? (perfect)
by tye (Cardinal) on Oct 23, 2012 at 17:35 UTC

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

    - tye        

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

        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        

Re^7: Does IO::Select work? (Problem partially resolved)
by BrowserUk (Pope) on Oct 23, 2012 at 20:45 UTC
    My main point was, the developer has full control over the life span of a socket.

    Sorry to do this to you, but the CEO of BodyForm has a few uncomfortable truths for you.


    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

      13,456 likes, 251 dislikes

      Dang, I think yesterday it was 250 likes

        Sod slashdotted; they've been PMt'd.


        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

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (9)
As of 2014-12-23 04:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (135 votes), past polls