Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!POSTGRES.BERKELEY.EDU!dillon
From: dillon@POSTGRES.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Exec signals
Message-ID: <8905010604.AA20949@postgres.Berkeley.EDU>
Date: 1 May 89 06:04:28 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 26

:Why is it that signals often go off randomly?  For example, assume that
:a replyport is set up to receive replies from a device driver when an 
:operation is complete.
:
:	wakeupmask = wait(1L<<request.whatever...mp_sigbit);
:
:Why should I have to do a CheckIO() to make sure the operation is complete?
:shouldn't the signal bit in wakeupmask be enough?

	Ahh.. they actually don't go off randomly.  You will not necessarily
use a different reply port for each request.  I never do!  I always use the
same reply port to sink ALL my IO requests... once I even used a window's
UserPort as a sink for IO requests.  In anycase, whenever you have a signal
bit being shared by more than one entity you can't make such assumptions.

	Even if you are careful, it is a good idea to use CheckIO().  In
fact, I should say, you had better use CheckIO().  The reason is simple:
The signal is not always cleared by WaitIO(), it depends whether the request
gets returned before or after you call WaitIO().  Thus, while relying on
the signal may work for the first go around, it may not on the second.  One
could go through all the possible cases and a solution not using CheckIO()
exists for all of them, but is different every time (for instance, using
SendIO()/Wait()/Remove() vs SendIO()/WaitIO() vs vs vs...).  So make your
life simple!  Use CheckIO()!

						-Matt