From owner-freebsd-arch Mon Aug 21 21:28: 6 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 6160B37B423 for ; Mon, 21 Aug 2000 21:28:04 -0700 (PDT) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id AAA27185; Tue, 22 Aug 2000 00:27:46 -0400 (EDT) Date: Tue, 22 Aug 2000 00:27:46 -0400 (EDT) From: Daniel Eischen To: Alfred Perlstein Cc: "Jacques A. Vidrine" , freebsd-arch@FreeBSD.ORG Subject: Re: Is it time yet? [was Re: Weak symbols] In-Reply-To: <20000821182346.L4854@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 21 Aug 2000, Alfred Perlstein wrote: > * Daniel Eischen [000821 17:47] wrote: > > > > When we want to (someday) build libpthread, it will have to be linkable > > with libc. If we wanted the threads library to be able to catch internal > > calls to _read(), then _read() can't be the actual system call. This > > should not be a problem with a "scheduler activations"-based threads > > library (we shouldn't have to wrap potentially blocking syscalls). I'd > > like to make this assumption, but wouldn't rule out the possibility of > > having to override a few library/system calls from libpthread. > > If libpthread could try to use a kqueue mechanism for sockets/pipes/fifo > and only fall back to scheduler activations for disk IO we'd be in > good shape. I don't think this is a good idea. A system call is a system call, whether its kqueue() or read(). It's much easier to let a read() pass through to the kernel and use SA, than to try and make the threads library understand the difference between a read on a socket and a read from a disk file. When the request(s) completes, it takes a kernel -> user level notification, regardless of whether it is kevent/kqueue or SA. I really think the user threads library should be as dumb as possible with regard to the types of I/O requests. Using SA, we avoid having to do the kind of call conversion that you'd have to do if you used kqueue. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message