From owner-freebsd-current Mon Jun 26 1:18: 8 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.osd.bsdi.com (ppp-179.dialup.clari.net.au [203.57.253.179]) by hub.freebsd.org (Postfix) with ESMTP id 2B20D37BA78 for ; Mon, 26 Jun 2000 01:18:01 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id BAA00624; Mon, 26 Jun 2000 01:23:33 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200006260823.BAA00624@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Nick Hibma Cc: FreeBSD CURRENT Mailing List Subject: Re: irunning, width in bits. In-reply-to: Your message of "Wed, 21 Jun 2000 00:40:31 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 Jun 2000 01:23:32 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > What about shared interrupts? How are they going to be treated? With the > spl leaving the arena it somehow looks feasible to run one interrupt > source on two different threads if there are two pieces of hardware > attached to the same interrupt line. > > >From what I understood from dfr, when switching away from an interrupt > handler it is converted into a full thread. When the second piece of > hardware fires an interrupt it could then run at the same time. I thought of this almost immediately - it's a bad idea though because it makes it hard to determine when to EOI an interrupt. If you expect to perform significant processing in your interrupt handler, you should consider a taskq. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message