Contents | < Browse | Browse >
e x e c . l i b r a r y FindSemaphore
__________________________________________________________________________
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
REPORT Forbid() missing, unreliable result
SEVERITY Level 2
EXPLANATION You MUST freeze multitasking before searching a
public Semaphore. Otherwise the semaphore could be
removed shortly after you've got the pointer. An access
to the structure will then throw Enforcer hits in best
case, or it will just trash memory. Also see AutoDocs!
DEADLY In DEADLY mode, this function call will return the
true return code only if multitasking was forbidden.
Otherwise it will pass NULL if the Semaphore wasn't
there anyhow, or 0xFACEDEAD if the Semaphore was found.
So, just finding out if this semaphore existed will still
work, but accessing it will cause Enforcer hits.
REMARK Some people claim that this hit is annoying, since they
consider this practice to be legal if you only want to
find out if a port is available or not.
I don't think so. There is still a slight chance to
crash the system. Imagine your program is iterating the
list without Forbid(), looking for a certain Node B
which comes after Node A. Now, while FindPort() is
fetching Node A, a scheduling occurs and another process
gets the processor. This other process now removes Node A
from the list and changes its memory contents. If your
program then gets the processor back, it will get a
completely messed up 'Node A', and will crash.
It is sad, but as long as AmigaOS does not provide a
semaphore mechanism for public lists, we must use Forbid()
if we iterate through them.