From: KOSAKI Motohiro Date: 2011-04-13T21:14:10+09:00 Subject: [ruby-core:35735] Re: [Ruby 1.9 - Bug #4558][Assigned] TestSocket#test_closed_read fails after r31230 Hi 2011/4/13 U.Nakamura : > Hello, > > In message "[ruby-core:35725] Re: [Ruby 1.9 - Bug #4558][Assigned] TestSocket#test_closed_read fails after r31230" > � �on Apr.12,2011 21:31:46, 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. >> �1) 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. >> �2) At [ruby-core:35203], We decided IO.close() raise exception to >> othread threads >> � � �and then they should wake up as ruby-1.8. >> � � �Should we think win32 is exception for this rule? > > I see. �Hmm... > > 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?