From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 20 07:36:25 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 581DE16A4CE for ; Sun, 20 Feb 2005 07:36:25 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4289643D31 for ; Sun, 20 Feb 2005 07:36:22 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id j1K7aHoG010051; Sun, 20 Feb 2005 18:06:18 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Sun, 20 Feb 2005 18:05:36 +1030 User-Agent: KMail/1.7.92 References: <20050220054251.GB28983@cirb503493.alcatel.com.au> In-Reply-To: <20050220054251.GB28983@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3245070.EYrDeGpbY3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200502201805.43307.doconnor@gsoft.com.au> X-Spam-Score: -5.1 () IN_REP_TO,MIME_LONG_LINE_QP,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: Peter Jeremy Subject: Re: Signalling a process from a INTR_FAST handler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2005 07:36:25 -0000 --nextPart3245070.EYrDeGpbY3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sun, 20 Feb 2005 16:12, Peter Jeremy wrote: > I have a hardware interrupt handler that has to forward a signal to > userland and that I'd like to mark INTR_FAST. AFAIK, the normal way > to forward a signal is: > if ((p =3D pfind(sc->pid_to_signal)) !=3D NULL) { > psignal(p, SIGUSR2); > PROC_UNLOCK(p); > } > > But pfind(9) does a PROC_LOCK() which implies it can sleep and therefore > can't be used by an INTR_FAST handler. > > Firstly, am I correct? If so, is there an alternative approach I can use? I think you are, and I think the only way to do it is to schedule another=20 kernel [heavy] thread to do the wakeup. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart3245070.EYrDeGpbY3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBCGD3P5ZPcIHs/zowRApNPAJ4osMseZ+cUq/nMBhhbnbmiiuqXSACeOTa0 xWcg0/3Dt4vC4bk4T5GehXQ= =pRNJ -----END PGP SIGNATURE----- --nextPart3245070.EYrDeGpbY3--