TIP: Click on subject to list as thread! ANSI
echo: cis.os9.68000.osk
to: Joachim Terasa 100421,2472 (X)
from: Ian J Shearer 100410,2733
date: 1995-05-24 13:22:10
subject: #20933-#Alarms `disappearing`

#: 20968 S12/OS9/68000 (OSK)
    24-May-95  13:22:10
Sb: #20933-#Alarms 'disappearing'
Fm: Ian J Shearer 100410,2733
To: Joachim Terasa 100421,2472 (X)

If you're interested, I found the cause of my problem.  If you delete an alarm
at the same time as it expires, it is possible to accidentally delete a
completely different alarm from another process.  It goes something like this;

        Task A starts to delete an alarm
        The alarm being deleted expires
        A task/process switch occurs
        Task B creates a new alarm, which uses the old 'slot' of the
          task A alarm
        Task A completes deleting the alarm, but gets the new alarm
          from task B by mistake

This is something to do with OS-9 marking an alarm 'slot' as free before it
truely is.  Version 3.0 gives a partial solution, since you can prevent a task
from deleting alarms  with other owner IDs; if you spawned all the tasks from
one parent, as I did, this won't help.

The workaround is to use periodic (repeating) alarms, then kill them in
response to the first signal they generate.  In other words, the ONLY safe way
to use alarms is to avoid single-shot alarms like the plague.  Disappointing
but true.

There are 2 Replies.

SOURCE: compuserve via textfiles.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.