Contents | < Browse | Browse >

 e x e c . l i b r a r y                                         FindPort 

REPORT          Forbid() missing, unreliable result

SEVERITY        Level 2

EXPLANATION     This is one of the hits that occures most. You MUST
                freeze multitasking before searching through the public
                list for a message port. Otherwise the port could be
                shut up shortly after you've got the pointer. The next
                PutMsg() 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 Port wasn't there
                anyhow, or 0xFACEDEAD if the Port was found. So, just
                finding out if this port 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.