X

ShrinkWrap and RAM Doubler conflict

ShrinkWrap and RAM Doubler conflict

CNET staff
2 min read
Kalman K. Brattman wrote me the following: "ShrinkWrap 2.1 (68K) is incompatible with Ram Doubler 1.6.2 for the Mac. Its author, Chad Magendanz, acknowledged the problem, stating that he already has a fix for it which will be incorporated into the 3.0 release of ShrinkWrap."

I emailed Chad about this matter and he wrote back the following (somewhat technical but informative!) reply:

"I've received a couple of reports about this, but have been unable to reproduce the bug myself. I suspect it's because RAM Doubler is making calls to the ShrinkWrap driver with interrupts disabled, then ShrinkWrap makes a synchronous call to another driver, resulting in a deadlock condition in vSyncWait. This is a scenario that many driver developers, including myself, hadn't fully understood until Quinn "The Eskimo" released TechNote 1067 back in September.

What insulated us all from this potentially nasty bug was the fact that the SCSI Manager was written to resolve these deadlock situations automatically. I suspect that there are some circumstances with RAM Doubler where the SCSI Manager is not able to perform its magic, causing the symptoms to resurface.

I first became aware of a problem when I noticed that deadlocks would sometimes occur when mounting disk images over the network with Open Transport, which does *not* automatically resolve these deadlocks. I made a fix to ShrinkWrap 2.1 to make only asynchronous for disk mounted over the network, but bet that I could get away with synchronous calls still for the SCSI Manager until I finished the driver redesign for ShrinkWrap 3.0. Apparently, I lost that bet.

The ShrinkWrap 3.0 driver, which is getting ready for beta release, should fix this problem by always using asynchronous calls to other drivers."

By the way, this new version should be released commercially as an Aladdin product.