At 6:07 PM -0700 1999/05/06, Bob Ebert wrote:
>At 10:23 AM -0700 5/6/99, Jim Schram wrote:
>>EvtEnqueueKey is called from within interrupt service routines and
>>background tasks. Neither the memory manager nor the feature manager can
>>safely be called from within an interrupt service routine -- you WILL
>>corrupt the dynamic and/or storage heaps, crashing randomly as a result,
>>possibly losing all user data in the device.
>
>Um, actually, it's not that bad. In reality, what will happen is the
>device will eventually hang when a button is pressed. The hack will
>attempt to acquire the memory manager semaphore from an interrupt, which
>will block and the other task that has the semaphore will never get a
>timeslice to release the semaphore because you're in an interrupt.
Actually, no, it is that bad. Not always, but sometimes.
I was hoping to avoid a lengthy explanation, but one would probably benefit a number
of folks in understanding at least one of the more subtle issues involved.
Exactly what happens depends entirely on which AMX task is active at the time of the
call, the interrupt level, any active kernel timers, and whether or not this is a
licensee's device running a modified version of our OS which may have its own trap
patches in-place circumventing or augmenting the OS' default behavior of an API.
For example:
Let's say AMX is giving time to the user interface task, and that task is busy doing
something in the data manager or memory manager. Trying to reserve the memory
semaphore from within the interrupt generated by a key press (which calls a
trap-patched EvtEnqueueKey which calls FtrGet and so on) will succeed (it's a counting
semaphore, similar to handle locking). If one of these managers is in a state of flux
-- compacting the heap for example -- executing any code in your hack that directly or
indirectly allocates or moves memory will corrupt the heap. Not guaranteed, but very
likely.
On the other hand, if some other task or kernel timer is active when the interrupt
occurs, reserving the semaphore will block and the scenario Bob described above will
occur.
Also keep in mind that the type of corruption that may result can be very subtle. It
might not affect anything for minutes, hours, days... but eventually it will cause a
problem, and the device will most likely crash.
Regards,
Jim Schram
3Com/Palm Computing
Partner Engineering
