Date: Tue, 22 Aug 2000 00:27:46 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: "Jacques A. Vidrine" <n@nectar.com>, freebsd-arch@FreeBSD.ORG Subject: Re: Is it time yet? [was Re: Weak symbols] Message-ID: <Pine.SUN.3.91.1000822000155.24514A-100000@pcnet1.pcnet.com> In-Reply-To: <20000821182346.L4854@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 21 Aug 2000, Alfred Perlstein wrote: > * Daniel Eischen <eischen@vigrid.com> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1000822000155.24514A-100000>