Can't do that

Apparently there are quite a few things you can't do from within a sampled sound callback on PalmOS 5, I mean Garnet. As you may be aware, the callback runs in a separate thread of execution from the rest of the application. Therefore one of the things you need to be careful of is synchronization with your main thread. There are no synchronization constructs available to 68k apps or PNOlets, so you've got to implement your own. (Open up your favorite operating system book and look up spin locks. With audio callbacks, you can modify spin locks in such a way as to avoid pegging the CPU. I'll leave this as an exercise.) The other option is to avoid doing things that require synchronization between the threads, which is probably a good idea anyway.

Besides the threading problems, there are also problems with certain OS functions that appear not to be thread safe. We've run into the following functions that seem to have problems:

• DmDeleteDatabase - calling this from the audio callback on some devices causes resource-management functions (e.g. DmGetResource) to later fail in catastrophic ways.
  
• PrefGetPreference - calling this from the audio callback at precisely the wrong time (i.e. when another thread is accessing the system preferences DB) causes a Fatal alert because the system preferences DB can't be opened.
  
• FileClose - just found this today. Calling this from the audio callback corrupts something and leads to hard-to-track-down crashes sometime later (possibly after leaving your app and coming back, which is kind of scary!)