🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.amiga.tech
Article #12443

Re: Exec signals

#12443
From: Matt Dillon
Date: Mon, 01 May 1989 06:04
26 lines
1737 bytes
: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
Technical Details
Message-ID: <8905010604.AA20949@postgres.Berkeley.EDU>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!POSTGRES.BERKELEY.EDU!dillon

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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