99% of the time it'll probably the contents of stderr.txt on the first retry when the error condition is triggered. The extra four retries are to deal with the possibility we have to wait on various forms of anti-malware and content indexers to have had their way with the file as well.

Special purpose software such as virus scanners and anti-malware usually have kernel mode components that make sure they get first dibs on files after they have been released by the apps that created them.

Normal Windows software hooks into the file system notification API and lets Windows tell it when it is its turns to fiddle with the file. BOINC being a cross-platform async polling app instead relies of checking to see if it can successfully access the file.

For those couple days that I was running with the Process Monitor logging turned on, it never required more than one re-try to be successful. However, the AV on those boxes (Security Essentials on the xw9400 and Windows Defender on the T7400) didn't seem to be taking any interest in those files. It was certainly informative, however, to see that Windows Search indexing was accounting for a significant amount of activity on the T7400 (Message 1701586). Seeing no purpose in indexing such transient files, I was pretty quick to turn the indexing off for the whole slots tree. So, another efficiency improvement resulting from the testing. :^)

Now, having just looked at that code block again with my non-C++ trained eyes, I'm wondering whether I've still misinterpreted what will happen if that 5-second grace period expires. Does the Sharing Violation actually end up causing that Error Code 32 to be reported, or does the normal code path simply resume, presumably still producing a truncated stderr.txt? I dunno, some expert is gonna hafta 'splain that to me! ;^)

To my (also untrained) eye, it looks like it simply falls out of the bottom, five seconds later. So it does what it was going to do anyway, but slower.

If that's the case, then it will definitely be a significant improvement for S@h, too, even if it is more of a patch than a true fix. And to use Jason's raft analogy ("Fingers crossed this raft never gets used on the open ocean."), you may not want to launch a raft with this sort of patch, but if you're already in the middle of the ocean, it sure will be helpful to patch the pinholes any way you can, until you can get the raft back to shore and build a whole new one!

Followed up on this with clear eyeballs as promised. I have no issues with the method or logic. It'll just keep trying to open the file for up to 5 seconds (rather than simply a fixed delay). The comment doesn't really say why a magic number of 5 seconds ( not 3, 9 or 42 ), and it only tries once per second for access, but should be way better as your results would suggest.

And also that in the Milkyway case, it's the OpenCL component of the NVidia driver/runtime suite which is active.

If I could just interject one thing (without understanding much other than CUDA in that post), it would be that truncated Stderr is not unique to the NVIDIA GPUs. It happens on ATI cards and CPUs as well.

I don't see the commit mode change actually fixing the problem. The writes have been delayed somewhere by something for some reason.

[Edit:] for the important technical points you make, and questions you raise, the core issues relate to that multithreaded C-Runtimes became standard circa 2005 in the case of Windows, so it requires a mindset shift from sequential/procedural to parallel and out-of order operation. That's proven over time to be a lot tougher than most I know expected, and for me too. Non-deterministic behaviour is a pretty big red flag for this kindof thing too.

... Notice that I said "modification" rather than "fix", because now that I believe I've actually caught on to what that code change is doing (a light bulb that flashed on about 2 A.M., of course), I'm wondering if this might just be exchanging one type of rare task failure ("instant" Invalid) for another (Error while computing - Error code 32), at least from a S@h perspective. (For MW, it probably really is a fix.)

Lol, when you reach that point, It's actually a pretty unique feeling isn't it ? Kindof relief that something's done, mixed with dissapointment at the particular choice of chewing gum, bits of string, and duct tape to plug the holes.

Fingers crossed this raft never gets used on the open ocean.

[E.T calls up via Arecibo just to ask "What the heck is that thing you're driving? Impressive! Don't build spaceships though!"

Heh, my first reaction when I thought I understood why the truncations really were fixed was quite satisfying, the second reaction, after crawling back into bed, was to wonder whether the cure might simply introduce a different disease, not exactly a sleep-inducing thought.

Now, having just looked at that code block again with my non-C++ trained eyes, I'm wondering whether I've still misinterpreted what will happen if that 5-second grace period expires. Does the Sharing Violation actually end up causing that Error Code 32 to be reported, or does the normal code path simply resume, presumably still producing a truncated stderr.txt? I dunno, some expert is gonna hafta 'splain that to me! ;^)

Boinc committee next meeting, urgent matters: "Oh no! the Windows people have discovered process monitor!"

A lot becomes clearer if you go look at the scheduler authentication code. It makes this part look solid as... well, something really really solid.

[Edit:] sometimes not being trained in something can be an advantage too. It's easier to point out that it doesn't work, lol.

[Edit:] Now that I know the reasoning, and that not much of it applies for specific applications at all, optional exit handling strategies & thread management become a lot easier to work in.

Only problem there, is they decided (for unknown reasons) to use an asynchronous TerminateProcess() call and put a 1 second sleep and hard crash, instead of waiting on a synchronisation primitive.

If one of the terminated threads in the process holds a lock and the DLL detach code in one of the loaded DLLs attempts to acquire the same lock, then calling ExitProcess results in a deadlock. In contrast, if a process terminates by calling TerminateProcess, the DLLs that the process is attached to are not notified of the process termination. Therefore, if you do not know the state of all threads in your process, it is better to call TerminateProcess than ExitProcess. Note that returning from the main function of an application results in a call to ExitProcess.

No idea why the entire codebase seems to be allergic to synchronisation, and likes to use magic numbers (fixed time intervals) on a non-realtime OS.

You'll just have to email the PMC email list, which errm no one knows what it is. ;-)

This might be a bit simplistic, but it seems to me that if BOINC 7 recognises an RDP connection, it would work correctly if it remembered the state of the GPU at the connection time and resets it when the connection is broken.

So if the GPU was disabled it would remain disabled but if it was enabled it would be re-enabled.

I see. That would be a problem. Is this a remote thing or just the switch user option? Can you not tell the difference between a switch user and a remote connection or are they exactly the same thing? If they're not the same thing, can you tell when the original user switches back?

I wonder what happens in BOINC V6 if another user RDPs to my work PC.

If I remember, I'll give it a test next time I'm physically in the office. Of course only one user at a time can RDP to a PC. If another user tries, the first user is thrown out. At least that's how it worked a few years ago. So all BOINC V6 has to do is recognise the disconnection, connection in the right order to still work properly. Or does it go to sleep and can't catch those steps. Hmm! I can see the problems.

Rick

FYI, I have reverted to BOINC V6 and it does handle RDP in a well behaved way.

Below is an extract of the log showing me connecting, disconnecting 10 minutes later and then reconnecting.

If the way that BOINC V7 handles RDP is not a bug, it's certainly not an enhancement. I guess most users don't use RDP, but I have to.

Rick


-- After connecting
10-Jul-2013 19:22:39 [---] GPUs have become unusable; disabling tasks

10-Jul-2013 19:23:02 [SETI@home] update requested by user
10-Jul-2013 19:23:05 [SETI@home] Sending scheduler request: Requested by user.
10-Jul-2013 19:23:05 [SETI@home] Reporting 2 completed tasks, not requesting new tasks
10-Jul-2013 19:23:09 [SETI@home] Scheduler request completed

-- After disconnecting - Notice the AP GPU task restarting.
10-Jul-2013 19:33:14 [---] GPUs have become usable; enabling tasks
10-Jul-2013 19:33:16 [SETI@home] Restarting task ap_23fe09aa_B5_P1_00173_20130710_30000.wu_1 using astropulse_v6 version 606

-- After reconnecting
10-Jul-2013 19:34:19 [---] GPUs have become unusable; disabling tasks

or novell network shares

Just so long as you're not still running IPX/SPX?? :-)

IPX/SPX had one huge advantage not shared by NetBIOS over TCP/IP: it's drop-dead simple.

Our "modern" windows networks were born as an IBM product designed for networks around five nodes, and have been continually kluged to make them "scale" to the size of an enterprise. "Browsers" to cut down on broadcasts, "Master Browsers" to cut down on browser traffic, Domain Controllers to layer better security, WINS to map NetBIOS names to IP addresses, then the DNS kluge to replace WINS (and put internal and external resolution into the same pile) and finally Active Directory.

All of that while IPX just worked.

I must say I'm not sure that there is any actual research been done at all anymore. It's not like we see any of it or hear anything about it.

Perhaps they did finish the project when the classic SETI ended and this is just a sceem to get money. I mean, they are sending out those e-mails begging for money, like any spam e-mail company.

@ Rom, We have an error that is affecting this XP64 Client and app. Could You please Help on this?