[ruby-core:35735] Re: [Ruby 1.9 - Bug #4558][Assigned] TestSocket#test_closed_read fails after r31230

Hi

2011/4/13 U.Nakamura <[e-mail]>:
> Hello,
>
> In message "[ruby-core:35725] Re: [Ruby 1.9 - Bug #4558][Assigned] TestSocket#test_closed_read fails after r31230"
> n Apr.12,2011 21:31:46, <[e-mail]> wrote:
>> > Or, please explain grounds from which this test should be accepted as behavior of ruby.
>>
>> I succuseeded to reporoduce this issue. On win32, IO.close() cause hang-up.
>> So, I think we have to discuss two thing.
>> ) Why close() makes hang-up? Is it acceptable behavior?
>
> MSVCRT's fds have their own locks.
> MSVCRT locks fds when accessing them -- reading, writing,
> closing, etc.
> The author of MSVCRT obviously intended the behavior, I think.

ok, I see.


>> ) At [ruby-core:35203], We decided IO.close() raise exception to
>> othread threads
>> nd then they should wake up as ruby-1.8.
>> hould we think win32 is exception for this rule?
>
> I see. mm...
>
> Is the behavior that close() doesn't block and the I/O operations
> of other threads are interrupted defind by posix or some specifications?

No. It's purely implementation defined.

> We found this problem in Windows this time, but might there be
> other platforms which have same problem?

It's possible.
So, now I'm incline to revert r30852.

nobu, What do you think?