Logged in as Guest Sun, Oct. 21st, 7:38 AM.
|
|
|
|
|
Recently, I have heard rumblings that the new Tungsten T5 is a bit on the unstable side, but until recently, I dismissed most of them. That is, until I was forced to come face to face with the harsh reality that is NVFS. Now, just to be clear, I don't work for palmOne or PalmSource so I really have no idea other than intuitive guesses why it crashes, but if you want to see the reported instability in action, throw this code into a small PRC and run it on a T5:
//NOTE: Obviously, you need to make sure that the database
//exists, but for the sake of simplicity, I have left error
//checking and the standard 'boilerplate' DB code out.
LocalID id = DmFindDatabase(0, "____TEMP_DB____");
DmOpenRef db = DmOpenDatabase(0, id, dmModeReadWrite);
for (UInt16 i = 0; i < 40000; i++)
{
UInt16 recordId = 0xFFFF;
MemHandle handle = DmNewRecord(db, &recordId, 1024);
DmReleaseRecord(db, recordId, true);
//This part is optional, but it lets you at least see
//that something is happening...
if (! (i % 1000))
{
char msg[64];
StrPrintF(msg, "Records created: %u", i);
ErrAlertCustom(0, msg, "", "");
}
}
You should find that after what seems like an inexorable amount of time, it will crash with either a generic "Fatal Alert" or a "DataMgr.c, Line:11321, Index out of range" fatal alert. Quite frankly, I was shocked by how easy it was to make this happen. It seems to me like a pretty simple/obvious unit test when you implement a new file system to create a large number of generic files (or in this case records) in a loop and make sure everything works acceptably. Obviously, no one stopped to do that here. I have a lot more to write about my experiences with NVFS, but I'll save that for later. |
|
| Submitted by bosshogg on Wednesday the 31st 1970f December 1969, at 04:00 | |
