From owner-freebsd-arch@FreeBSD.ORG Thu Apr 15 17:38:59 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 91F8216A4CF; Thu, 15 Apr 2004 17:38:59 -0700 (PDT) Received: from localhost (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i3G0cwni020043; Thu, 15 Apr 2004 20:38:59 -0400 (EDT) (envelope-from green@green.homeunix.org) Message-Id: <200404160038.i3G0cwni020043@green.homeunix.org> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Robert Watson , Seigo Tanimura , Pawel Jakub Dawidek , freebsd-arch@freebsd.org In-Reply-To: Message from John-Mark Gurney of "Thu, 15 Apr 2004 15:39:20 PDT." <20040415223920.GT567@funkthat.com> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Apr 2004 20:38:58 -0400 Sender: green@green.homeunix.org Subject: Re: locking down kqueue (was some other completely unrelated topic) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2004 00:39:00 -0000 John-Mark Gurney wrote: > Brian F. Feldman wrote this message on Thu, Apr 15, 2004 at 16:36 -0400: > > Nothing is currently designed to work with anything even remotely not > > looking like spl(), so we have to either flatten it out (using workqueues) > > or change semantics so that when KNOTE() is called it acts like the closure > > that we pretend it is. Of course, the easy way to do this is with a worker > > queue/condvar/mutex/thread. What other ways do we have available to turn > > KNOTE() into a closure, bearing in mind that the entire point of the > > mechanism is that there is no memory allocation at the time of event > > generation -- only when events are defined (by the user or recursively by > > other events). > > The proc case should be treated special as it is an [ab]use of the kevent > system with following children... I'm looking at it more.. It's stupid, hopeless, and an abomination. I'm removing it. The only way it can possibly work to report failure to the "parent" knote at the same time is if KNOTE() and kqueue_register() have the exact same locks -- not gonna happen if there are ANY non-global kqueue locks at all! I'm going to replace it with what it SHOULD have been: implemented, at the end of kevent() after kqueue_scan() as a shortcut that doesn't leave the kernel but does not do any of the horrible, evil, SINGLE special case that makes me have to try to do this to accomodate it: if (kn->kn_fop->f_event(kn, hint) || kn->kn_kq->kq_state & KQ_UPCALL) { int enqueued = 0, upcall; upcall = kn->kn_kq->kq_state & KQ_UPCALL; KNOTE_ACTIVATE(kn, enqueued); if (upcall || enqueued) { struct kevent upkev; long uperrnote; if (upcall) { upkev = kn->kn_kq->kq_upcall; uperrnote = kn->kn_kq->kq_uperror; kn->kn_kq->kq_state &= ~KQ_UPCALL; } mtx_unlock(&knote_mtx); mtx_unlock(&kn->kn_kq->kq_mtx); mtx_unlock(&klist_mtx); if (upcall) { if (kqueue_register(kn->kn_kq, &upkev, curthread) != 0) { } } -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\