From owner-freebsd-hackers Sat Apr 25 16:55:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA11261 for freebsd-hackers-outgoing; Sat, 25 Apr 1998 16:55:06 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA11247; Sat, 25 Apr 1998 16:54:58 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.8.8/8.8.7) id JAA09319; Sun, 26 Apr 1998 09:54:04 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199804252354.JAA09319@cimlogic.com.au> Subject: Re: threads performance In-Reply-To: <199804252306.SAA00505@dyson.iquest.net> from "John S. Dyson" at "Apr 25, 98 06:06:58 pm" To: dyson@FreeBSD.ORG Date: Sun, 26 Apr 1998 09:54:03 +1000 (EST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John S. Dyson wrote: > > Why this hurts so much be comparison to other platforms (which > > supposedly also do this) is another question entirely. > > > We need to use a deferred mechanism, a lot like our interrupt > code. The issue of blocking syscalls makes this "not worth doing". It would only be possible for -current, anyway. I'd prefer that we concentrate on the kernel thread interface so that the blocking syscall issue goes away. And with it goes the need to block signals. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message