If BrowserUK said it, yes, he is sure. And sure to be right. Seriously.

Well, if BrowserUK is so sure, and you know that he is right, then all I'd like to see is the description of situations where the kernel would close your file descriptor without you requesting it. Once you show it to me, I'll be happy to say, that he is right. Until you've done it, I prefer to stick to my own experience. I believe this is fair enough :)

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.
[download]

And:

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

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;
[download]

But, this usually not:

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

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

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