Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

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

by BrowserUk (Pope)
on Oct 23, 2012 at 10:11 UTC ( #1000462=note: print w/ replies, xml ) Need Help??


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

then all I'd like to see is the description of situations where the kernel would close your file descriptor

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

Perl is perhaps a more likely target for responsibility. For example:

{ my $sock = new IO::Socket::INET( 'localhost:12345' ); } ## Here the handle is closed.

And:

for( 1 .. 2 ){ my $sock = new IO::Socket::INET( 'localhost:12345' ); } ## The first handle was implicitly closed during the second iteration.

These examples probably won't convince you, because the scoping is too obvious. But scoping isn't always so obvious, especially when programming in the "global state and gotos" style often required by event-driven architectures.

Similarly, this is normally perfectly fine:

... my $client = $svr->accept; async { ## do things with $client }->detach;

But, this usually not:

... my $client = $svr->accept; async { sleep 10; ## attempts to use $client fail }->detach;

The reason is that before the thread gets around to using its copy of the client handle, the parent thread has accepted another client. Now imagine the sleep isn't a programmed delay, but rather one caused by system loading (cpu; memory; IO) preventing the new thread getting up and running in a timely manner, so that the parent thread implicitly overwrite (and therefore closes) $client before the child thread gets to the point where it increments the reference count.

But you'll dismiss that as a "threads-issue".

I can't offer you an explanation of the linux example I cited -- I don't know the guy, nor do I do Linux -- but if the p5p guys took his perlbug seriously enough to patch perl; that's good enough for me to believe that it was a real issue.

I can also find other references to linux sockets mysteriously going awol, even outside of Perl. What I cannot do is pass judgement on the validity of the claims.

But even if every single occasion when an attempt is made to remove a closed file handle from an IO::Select object is down to programmer error; silently doing nothing and thus screwing the entire select loop is ... is ... shall we stick with: not very friendly.


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


Comment on Re^5: Does IO::Select work? (Problem partially resolved)
Select or Download Code
Re^6: Does IO::Select work? (Problem partially resolved)
by andal (Friar) on Oct 23, 2012 at 14:36 UTC
    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 :)

      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

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

      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

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (7)
As of 2014-12-26 05:14 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

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





    Results (165 votes), past polls