Hi

2011/4/13 U.Nakamura <usa / garbagecollect.jp>:
> Hello,
>
> In message "[ruby-core:35725] Re: [Ruby 1.9 - Bug #4558][Assigned] TestSo=
cket#test_closed_read fails after r31230"
> =A0 =A0on Apr.12,2011 21:31:46, <kosaki.motohiro / gmail.com> 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.
>> =A01) 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.


>> =A02) At [ruby-core:35203], We decided IO.close() raise exception to
>> othread threads
>> =A0 =A0 =A0and then they should wake up as ruby-1.8.
>> =A0 =A0 =A0Should we think win32 is exception for this rule?
>
> I see. =A0Hmm...
>
> 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?