The Mac is Back
Tiny post, for anyone else wondering about high CPU utilization and slow or crashing network services on their Mac while running Parallels Desktop for the Mac 3.0. I've been a happy Parallels-er, running a few critical apps on a virtual PC while doing most everything else on my Mini Mac. (Not a speed-demon, but quiet, cool, and dual core.) After the upgrade to 3.0, I found Parallels was routinely sitting on 40% of my CPU, and causing network connectivity, especially in Safari, to totally suck.
I had to Force Quit Safari daily. That didn't make sense. A few other people seemed to suggest that file sharing might be the problem. I've disabled file sharing of the Windows folders into the Mac. This is a nice feature, but in practice I don't use it (or the reverse) terribly often. All my permanent files are on a central networked drive which serves both Macs and PCs in my house. Disabled the sharing, and all was better. Perhaps they'll fix this in their next patch and let me use more than 1 CPU in my virtual machine, or I'll have to join the hordes defecting to the newly rich VMWare.
Added 19 Aug 2007: It appears USB support is no picnic for Parallels either. By disabling USB devices when I'm not using them in the VM, CPU usage has dropped quite a bit also. It still sits at 13% when idle, which I find disturbing. Experiments with VMWare are ongoing.
Mono's VMWare Image: Sometimes a ZIP is not a ZIP
o it finally came down to it: I wanted to run Linux in order to test some Mono interoperability code. We are writing libraries that will be used in .NET/Windows environments as well as C++/Linux environments, and getting the pointer buggery correct is important. We've got a C++ program (with a 25 year pedigree) that needs to start using components we'd just as soon write using .NET.
This is a case where I am not comfortable just testing some things in Mono on OS X because the issue is not managed code, but specifically unmanaged code. OS X has enough of its own skeletons; I don't want to sweat the wrong details. So I've gone off to the Mono site and downloaded their most recent VMWare image. It downloads in 20 minutes or so and unzips in another five. In a strange twist, I found that if I unzipped it using OS X's command line unzip command, the command complained about corrupted zip entries. VMWare started the unzipped mess properly, but nothing quite worked right correctly in the resultant image. I used the GUI unzip (whatever happens when you double-click the ZIP file in Finder) and it worked like a charm. Humph.
So I guess my Linux world for the next few weeks or months will be openSUSE 10.2, Novell's pet distribution. We'll see how it goes. I love that every few years as I play with Linux I have to learn a new package management library.
Locked Out of My File!
Too many applications hold file locks unnecessarily by design. Nonetheless, for many purposes I often want to read those files and assume I'll be "lucky" and not get inconsistent data. Or perhaps I want to read some data (e.g. a magic cookie header to test format) that I know won't change even if the file is being written. For some reason the way to open a .NET FileStream for reading a locked file has always eluded me. If you want to read a file and are getting the following error !exploitable.
Unhandled Exception: System.IO.IOException: The process cannot
access the file 'blah.txt' because it is being used by another process.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access,
Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize,
FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access)
...
You just need to indicate explicitly that you're willing to share your file handle. In other words, you're feeling lucky, punk.
using (FileStream fs = new FileStream(@"blah.txt", FileMode.Open,
FileAccess.Read, FileShare.ReadWrite))
Console.Out.WriteLine(fs.ReadByte());
The FileShare.ReadWrite indicates you're willing to share this file with people who are reading and writing to it. Once you think about it that way, it's obvious. For some reason, I kept looking for flags that indicated how little I wanted to touch the file, and this flag didn't jump out at me.