Front page | perl.perl5.porters |
Postings from March 2014
On Wed, 19 Mar 2014 11:42:43 +0100, Nicholas Clark <nick@ccl4.org> wrote: > On Wed, Mar 19, 2014 at 11:37:35AM +0100, Christian Walde wrote: >> On Wed, 19 Mar 2014 10:30:57 +0100, Nicholas Clark <nick@ccl4.org> >> wrote: >>> On Wed, Mar 19, 2014 at 12:50:00AM -0500, George Greer wrote: >>> >>>> [default] -DDEBUGGING -Duseithreads >>>> ../cpan/Win32API-File/t/file.t..............................FAILED >>>> Non-zero exit status: 13 >>>> Bad plan. You planned 270 tests but ran 1. >>> >>> That's really strange. 3 out of 4 pass. The other failed like this: >>> >>> Could not rmdir W32ApiF.tmp: Permission denied at t/file.t line 57. >> >> That looks like a timing issue. Adding `select undef, undef, undef, >> 0.25;` >> before the rmdir in question should fix that. > > Thanks for the feedback. I'm curious why. The relevant code is: [...] > > That code is single-threaded in Perl, isn't it? So what might be holding > "open" the directory, but lets it go within 0.25s. It's probably the glob read. I'm not an expert on the underlying code, so the following is something i explained to Tux at the QA hackathon based on my observations and understanding of Microsoft and Windows: Windows is a User OS, as opposed to the Server OS which is *nix. Microsoft thus gets a lot of really fucking dumb feedback from users, among which they probably got feedback like "doing things with files is slow". So Microsoft probably implemented a number of file operations in the manner that, to improve the user perception of operation speed, some of them return as soon as the Windows kernel determines that it can complete the operation, regardless of actual completion status. Supporting observation of this is that sometimes, with particularly big files on my SSD, a delete will be acknowledged, but even after multiple queries to the directory the file is still listed. Yet more attempts to delete it get the answer of "This file does not exist anymore." The same thing likely happens with smaller files, but on such a temporally microscopic scale that a quarter-second wait is plenty. -- With regards, Christian WaldeThread Previous | Thread Next