From: KOSAKI Motohiro Date: 2011-04-14T20:46:22+09:00 Subject: [ruby-core:35752] Re: [Ruby 1.9 - Bug #4558] TestSocket#test_closed_read fails after r31230 Hi 2011/4/14 Eric Wong : > KOSAKI Motohiro 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.