Hi

2011/4/14 Eric Wong <normalperson / yhbt.net>:
> KOSAKI Motohiro <kosaki.motohiro / gmail.com> wrote:
>> > Issue #4558 has been updated by Eric Wong.
>> >
>> > I consider either Errno::EBADF or IOError to be acceptable.
>>
>> Hmm...
>> I can't agree this. If EBADF can be observed, we can observe completely
>> unrelated file when a fd number was recycled just after close.
>
> Actually, I expect EBADF make any read/write-retry loop stop
> immediately, but yes, exposing IOError to user is better.

The problem is in no EBADF observed case. if following scenario can be happen.

CPU1                    CPU2
------------------------------------------
open() -> 5
                             close(5)
read(5) -> EBADF

following scenario should be happen too.

CPU1                    CPU2                    CPU3
-------------------------------------------------------------------
open() -> 5
                             close(5)
                                                         open() -> 5
read(5) -> success, but read different data.


>> Hmm...
>> If windows can't implement close() case, I doubt r30852 is correct fix.
>> Is this really worth that *nix and windows have different spec?
>
> If r30852 is reverted, Linux (and maybe other *nix) will still break
> threads out of blocking read/write with EBADF and
> rb_io_wait_*able(fptr->fd) will raise IOError as long as we
> assign fptr->fd = -1 before the actual close() call in IO#close.
>
> Maybe Windows (and possibly other OS) will be forced to call do_select()
> to implement behavior consistent with Linux.

???
I'm sorry, I haven't catch your point.
Which issue is solved by calling do_select()?


> On a related note, r30852 also has the problem with making IO#close an
> O(n) operation since it needs to scan through all threads (and I'd like
> to run thousands of threads :>).

I have no opinion. I like faster software, but I haven't seen close
makes performance bottleneck.