From owner-cvs-all Mon Sep 9 19:51: 0 2002 Delivered-To: cvs-all@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 87E7437B413; Mon, 9 Sep 2002 19:50:54 -0700 (PDT) Date: Mon, 9 Sep 2002 19:50:54 -0700 From: Juli Mallett To: Garrett Wollman Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/alpha/alpha machdep.c src/sys/i386/i386 machdep.c src/sys/ia64/ia64 machdep.c src/sys/pc98/i386 machdep.c src/sys/sparc64/sparc64 machdep.c Message-ID: <20020909195053.A752@FreeBSD.org> References: <200209071912.g87JCs0I062248@freefall.freebsd.org> <20020907163423.A14528@FreeBSD.org> <200209090341.g893fTNH062134@khavrinen.lcs.mit.edu> <20020908211352.A12924@FreeBSD.org> <200209091718.g89HIKpv066187@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200209091718.g89HIKpv066187@khavrinen.lcs.mit.edu>; from wollman@lcs.mit.edu on Mon, Sep 09, 2002 at 01:18:20PM -0400 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , , X-Towel: Yes X-LiveJournal: flata, jmallett X-Negacore: Yes Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * De: Garrett Wollman [ Data: 2002-09-09 ] [ Subjecte: Re: cvs commit: src/sys/alpha/alpha machdep.c src/sys/i386/i386 machdep.c src/sys/ia64/ia64 machdep.c src/sys/pc98/i386 machdep.c src/sys/sparc64/sparc64 machdep.c ] > < said: > > > Trap code, sender pid/uid (if another process sent it), ... I'd love to > > implement RTS, but it's still possible to move a lot of things to this > > structure, without implementing RTS. > > If we don't support reliable asynchronous delivery of this data, we > shouldn't encourage programs to use or depend on its presence for > asynchronous signals. You convinced me when I was taking off from Chicago Midway this morning. I'm writing a document now on how I see it all coming together, and my current todo list has a linked list of siginfo instead of the "one sig with info at a time" method we've had for the past N yes, which goes to implementing the queued delivery mechanisms of RTS, yes? Basically, I will have like a TAILQ of siginfo_t pointers, allocated from a UMA zone, and protected by their own lock (so that I can possibly get some of the signal processing out of PROC_LOCK - many threads can execute in the same part of some of that code, if the signal info is locked for INSERT) and along with the current things I have made go away, the siglist thing will be going away. This may incur great ABI breakage though, so I make no guarantees abotu delivering this for 5.0, but once I finish the first parts of what I am working on, we'll see what I can estimate. Thanks for the thoughts, juli. -- Juli Mallett | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger jmallett@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message