From owner-freebsd-arch Sun Oct 31 7:44:46 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 4232714A2C for ; Sun, 31 Oct 1999 07:44:43 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id QAA18756 for ; Sun, 31 Oct 1999 16:44:41 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA66374 for freebsd-arch@freebsd.org; Sun, 31 Oct 1999 16:44:41 +0100 (MET) Received: from green.myip.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id D9CD314A2C; Sun, 31 Oct 1999 07:44:31 -0800 (PST) (envelope-from green@FreeBSD.org) Received: from localhost ([127.0.0.1] ident=green) by green.myip.org with esmtp (Exim 3.02 #1) id 11hx9I-000EJA-00; Sun, 31 Oct 1999 10:44:04 -0500 Date: Sun, 31 Oct 1999 10:44:04 -0500 (EST) From: Brian Fundakowski Feldman X-Sender: green@green.myip.org To: "Daniel O'Connor" Cc: Warner Losh , freebsd-arch@freebsd.org, obrien@freebsd.org, chris@calldei.com Subject: Re: stpcpy() In-Reply-To: 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 Sun, 31 Oct 1999, Daniel O'Connor wrote: > > Well if you have a port which has this stuff in it (stpcpy, getopt, etc) then > where's the problem? If you are building by hand adding -I/usr/local/include > and -lcompatlinux to your makefile is easy, and if its a port its transparent > to the end user. I think this is the best idea proposed so far, just to chime in and be counted. It makes it easy for ports to provide this compatibilty, and that's what's important. > > --- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 9:51:54 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2567714D31 for ; Sun, 31 Oct 1999 09:51:48 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA19699 for ; Sun, 31 Oct 1999 18:51:47 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA66634 for freebsd-arch@freebsd.org; Sun, 31 Oct 1999 18:51:47 +0100 (MET) Received: from smtp01.wxs.nl (smtp01.wxs.nl [195.121.6.61]) by hub.freebsd.org (Postfix) with ESMTP id D621214D31; Sun, 31 Oct 1999 09:51:37 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org ([195.121.198.115]) by smtp01.wxs.nl (Netscape Messaging Server 3.61) with ESMTP id AAA6FBE; Sun, 31 Oct 1999 18:51:36 +0100 Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id SAA74012; Sun, 31 Oct 1999 18:50:47 +0100 (CET) (envelope-from asmodai) Date: Sun, 31 Oct 1999 18:50:47 +0100 From: Jeroen Ruigrok/Asmodai To: Brian Fundakowski Feldman Cc: "Daniel O'Connor" , Warner Losh , freebsd-arch@freebsd.org, obrien@freebsd.org, chris@calldei.com Subject: Re: stpcpy() Message-ID: <19991031185047.S64452@daemon.ninth-circle.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [19991031 18:11], Brian Fundakowski Feldman (green@freebsd.org) wrote: >On Sun, 31 Oct 1999, Daniel O'Connor wrote: > >> Well if you have a port which has this stuff in it (stpcpy, getopt, etc) then >> where's the problem? If you are building by hand adding -I/usr/local/include >> and -lcompatlinux to your makefile is easy, and if its a port its transparent >> to the end user. > >I think this is the best idea proposed so far, just to chime in and be >counted. It makes it easy for ports to provide this compatibilty, and >that's what's important. Couldn't agree more. We already have libgnugetopt in the ports, it would be easy to extend it to become compatlinux. On an aside, including getopt.h and unistd.h in one file is fun. Will look into this and fix up the port. -- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl The BSD Programmer's Documentation Project Network/Security Specialist BSD: Technical excellence at its best Go West, young man, and grow up with the country. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 10:16:28 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6DB0D14BDE for ; Sun, 31 Oct 1999 10:16:24 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA19890 for ; Sun, 31 Oct 1999 19:16:23 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA66743 for freebsd-arch@freebsd.org; Sun, 31 Oct 1999 19:16:22 +0100 (MET) Received: from bachue.usc.unal.edu.co (bachue.usc.unal.edu.co [168.176.3.20]) by hub.freebsd.org (Postfix) with ESMTP id 7637214BDE; Sun, 31 Oct 1999 10:13:13 -0800 (PST) (envelope-from pfgiffun@bachue.usc.unal.edu.co) Received: from bachue.usc.unal.edu.co ([168.176.3.32]) by bachue.usc.unal.edu.co (Netscape Messaging Server 3.6) with ESMTP id AAA4BEA; Sun, 31 Oct 1999 12:12:42 -0500 Message-ID: <381C868D.EF06E723@bachue.usc.unal.edu.co> Date: Sun, 31 Oct 1999 13:12:29 -0500 From: "Pedro F. Giffuni" Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: it,es-CO MIME-Version: 1.0 To: Brian Fundakowski Feldman Cc: freebsd-arch@freebsd.org Subject: Re: stpcpy() References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian Fundakowski Feldman wrote: > > On Sun, 31 Oct 1999, Daniel O'Connor wrote: > > > > > Well if you have a port which has this stuff in it (stpcpy, getopt, etc) then > > where's the problem? If you are building by hand adding -I/usr/local/include > > and -lcompatlinux to your makefile is easy, and if its a port its transparent > > to the end user. > > I think this is the best idea proposed so far, just to chime in and be > counted. It makes it easy for ports to provide this compatibilty, and > that's what's important. > -lcompatgnu perhaps would be a bit more generic, but I think it's bloat. What ports are we talking about ? Pedro. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 11:58:27 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 8AF0014E8C for ; Sun, 31 Oct 1999 11:58:24 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA20781 for ; Sun, 31 Oct 1999 20:58:23 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA67085 for freebsd-arch@freebsd.org; Sun, 31 Oct 1999 20:58:08 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 367C414E5E for ; Sun, 31 Oct 1999 11:58:01 -0800 (PST) (envelope-from julian@whistle.com) Received: from home.elischer.org (home.elischer.org [207.76.204.203]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id LAA23323 for ; Sun, 31 Oct 1999 11:58:00 -0800 (PST) Date: Sun, 31 Oct 1999 11:57:58 -0800 (PST) From: Julian Elischer X-Sender: julian@home.elischer.org To: freebsd-arch@freebsd.org Subject: discussions on this mailing list: 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 I am going to try host the following discussions on -arch over the next week. 1/ which direction (maybe multiple) are we going with threads. 2/ SMP. how to go about it from here.. 3/ In what ways should the VFS and the filesystems be changed/cleaned-up 4/ what about posix extensions such as scheduler classes... I will be doing them SERIALLY, by which I mean that While talking about #1 we don't wander off into #2 unless it directly affects #1. I will try add 'reminders of upcoming topics' regularly so people can hold off, knowing that their topic is on the way.. The first discussion will be on THREADS. A hot topic these days. and I will be posting a stating note on the topic in a short while.. This is a note to allow people to check that they are in -arch before the discussion starts. Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 13:15:45 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id CBEC714E76 for ; Sun, 31 Oct 1999 13:15:41 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA21410 for ; Sun, 31 Oct 1999 22:15:40 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA67392 for freebsd-arch@freebsd.org; Sun, 31 Oct 1999 22:15:40 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id E7A5A14E76 for ; Sun, 31 Oct 1999 13:15:28 -0800 (PST) (envelope-from julian@whistle.com) Received: from home.elischer.org (home.elischer.org [207.76.204.203]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id NAA24564; Sun, 31 Oct 1999 13:15:25 -0800 (PST) Date: Sun, 31 Oct 1999 13:15:23 -0800 (PST) From: Julian Elischer X-Sender: julian@home.elischer.org To: freebsd-arch@freebsd.org Subject: Threads models and FreeBSD. In-Reply-To: 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 This article will be reposted again for late comers in the discussion thread: There are several properties of threads that make them both good and bad programming models. John Ousterhout gave a keynote at Usenix a couple of years ago titled "threads considered harmful", which was both ammusing and had more that a shred of truth to it. Having said that, good thread support is essential able to support a lot of modern programs, and is a good way of ensuring that processes can make use of the increasing amount of MP machinery that is available. So what are the definitions that a thread enabled environment should possess? This not a definative list, and before we go on to solve the worlds threading problems, I'd like everyone to add their thoughts to this list so that we can agree about what problems we are trying to solve. If you are going to say "support pthreads" I'd like you to instead break that down to what we need to have in order to support pthreads.. I want pthreads to be a by-product (almost) of a good threading model, not the design goal. ------------ Thread properties ----------- 1/ Multiple independent 'threads of control' within a single process at user level. The most basic quality of threads. 2/ Ability to simultaneously schedule two threads over separate Processors. 3/ Inability of one thread to block aother thread unless they are intentionally synchronising. 4/ All threads see the same address space (exactly). 5/ All threads share the same file resources. 6/ (contentious) multiple theads should be bound to within the resource limits of the single process. 7/ Some well documeted scheme exists for handling signals and othe rasync events. 8/ Exit/shutdown protocol is well defined. 9/ there exists a set of primatives that allow threads to influence the in-process scheduling between themselves. 10/ your ideas here. Note, you an also suggest that I remove an idea. ------------- What we have at the moment: John Birrell's excelent work on user-level threading (libc_r), based originally on Chris provenzo's threading code has given us quite a bit of mileage so far, but it's starting to run out of steam with new requirements being more certain about kernel support requirements. It is notable that we already support Linux kernel threads on FreeBSD better than we support a native threads model. This is because we support the 'clone' system call through our rfork() code, and that is their basis for threading. As is common for this group of people, we have not adopted the Linux approach because it is considered to be 'too simplistic', assigning a separate kernel schedulable process to run each thread. Having said that, Amancio Hasty at one stage wrote a set of threading primitives to allow Kafe to run on FreeBSD using this scheme of threading, and Richard Seaman has a port of the Linuxthreads code to freeBSD at his website, http://lt.tar.com/ . This represents a useful piece of work and though it is presently not working on -current, hopefully this will be fixed soon. I believe there may be problems with the new signal stuff though I have not tested it myself. I also reference the following email in the archives: http://www.freebsd.org/cgi/getmsg.cgi?fetch=25000+30231+/usr/local/www/db/text/1999/freebsd-current/19990321.freebsd-current Peter dufault also has some work on scheduling that may be slightly relevent. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 14: 0:50 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2D84C14BE7 for ; Sun, 31 Oct 1999 14:00:43 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA21831 for ; Sun, 31 Oct 1999 23:00:42 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA67610 for freebsd-arch@freebsd.org; Sun, 31 Oct 1999 23:00:42 +0100 (MET) Received: by hub.freebsd.org (Postfix, from userid 758) id E757614BE7; Sun, 31 Oct 1999 14:00:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id D6B571CD424; Sun, 31 Oct 1999 14:00:33 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Sun, 31 Oct 1999 14:00:33 -0800 (PST) From: Kris Kennaway To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: 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 Sun, 31 Oct 1999, Julian Elischer wrote: > So what are the definitions that a thread enabled environment should > possess? This not a definative list, and before we go on to solve the > worlds threading problems, I'd like everyone to add their thoughts to this > list so that we can agree about what problems we are trying to solve. I'd appreciate it if Terry (or someone else) could clarify exactly the differences between the "scheduler activations" model described in the paper Daniel Eischen recently pointed out (which I thought was very well written): http://www.freebsd.org/~deischen/p95-anderson.pdf and the model he seems to prefer (async call gates). I've been rereading some of the old discussions about this, and they seem fairly similar. I'm not likely to be able to bring much to the discussion, but I'd appreciate the extra hint so I can understand it better :-) Kris ---- "Lisa, if you don't like your job, you don't strike - you just go in every day and do it real half-assed. It's the American Way." -- Homer Simpson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 14:12:26 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 681BF14F2A for ; Sun, 31 Oct 1999 14:12:23 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA21921 for ; Sun, 31 Oct 1999 23:12:22 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA67656 for freebsd-arch@freebsd.org; Sun, 31 Oct 1999 23:12:22 +0100 (MET) Received: from rah.star-gate.com (216-200-29-190.snj0.flashcom.net [216.200.29.194]) by hub.freebsd.org (Postfix) with ESMTP id C19B014F2A for ; Sun, 31 Oct 1999 14:12:15 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.3/8.8.8) with ESMTP id OAA08183; Sun, 31 Oct 1999 14:12:05 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199910312212.OAA08183@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-reply-to: Your message of "Sun, 31 Oct 1999 13:15:23 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 31 Oct 1999 14:12:05 -0800 From: Amancio Hasty Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Try to gather as much relevant on-line references as you can and create a simple web page for the project. The web page does not have to be anything fancy. Suggested outline: Your original posting Relevant commentaries from the list Research Projects and /or pointer to Commercial implemenations Bibliography The mailing lists are great for brainstorming however they are a poor information center. ------------------------- I wil try to dig up my old references on fast kernel locking. -- Amancio Hasty hasty@rah.star-gate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 14:42:43 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D016B14DC8 for ; Sun, 31 Oct 1999 14:42:31 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA22129 for ; Sun, 31 Oct 1999 23:42:28 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA67745 for freebsd-arch@freebsd.org; Sun, 31 Oct 1999 23:42:27 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 44EEF14BFD for ; Sun, 31 Oct 1999 14:38:58 -0800 (PST) (envelope-from julian@whistle.com) Received: from home.elischer.org (home.elischer.org [207.76.204.203]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id OAA25837 for ; Sun, 31 Oct 1999 14:38:54 -0800 (PST) Date: Sun, 31 Oct 1999 14:38:52 -0800 (PST) From: Julian Elischer X-Sender: julian@home.elischer.org To: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: 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 ok, but can he do it after we have decided what we are trying to achieve? On Sun, 31 Oct 1999, Kris Kennaway wrote: > On Sun, 31 Oct 1999, Julian Elischer wrote: > > > So what are the definitions that a thread enabled environment should > > possess? This not a definative list, and before we go on to solve the > > worlds threading problems, I'd like everyone to add their thoughts to this > > list so that we can agree about what problems we are trying to solve. > > I'd appreciate it if Terry (or someone else) could clarify exactly the > differences between the "scheduler activations" model described in the > paper Daniel Eischen recently pointed out (which I thought was very well > written): > > http://www.freebsd.org/~deischen/p95-anderson.pdf > > and the model he seems to prefer (async call gates). I've been rereading > some of the old discussions about this, and they seem fairly similar. > > I'm not likely to be able to bring much to the discussion, but I'd > appreciate the extra hint so I can understand it better :-) > > Kris > > ---- > "Lisa, if you don't like your job, you don't strike - you just go in every > day and do it real half-assed. It's the American Way." > -- Homer Simpson > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 14:51:47 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 59A0B14DC8 for ; Sun, 31 Oct 1999 14:51:33 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA22210 for ; Sun, 31 Oct 1999 23:51:30 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA67774 for freebsd-arch@freebsd.org; Sun, 31 Oct 1999 23:51:29 +0100 (MET) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 16E4214E9B for ; Sun, 31 Oct 1999 14:50:52 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@d60-025.leach.ucdavis.edu [169.237.60.25]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id OAA15453; Sun, 31 Oct 1999 14:50:50 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id OAA50062; Sun, 31 Oct 1999 14:50:49 -0800 (PST) (envelope-from obrien) Date: Sun, 31 Oct 1999 14:50:49 -0800 From: "David O'Brien" To: "Cc@FreeBSD.ORG"@FreeBSD.ORG:Dmitrij Tejblum , freebsd-arch@freebsd.org Subject: Re: stpcpy() Message-ID: <19991031145049.A90745@dragon.nuxi.com> Reply-To: obrien@NUXI.com References: <199910302228.CAA03763@tejblum.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from bde@zeta.org.au on Sun, Oct 31, 1999 at 02:07:26PM +1100 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Oct 31, 1999 at 02:07:26PM +1100, Bruce Evans wrote: > > Good stpcpy() could double performance in some cases. You would touch a > > symbol once where you previously touched it twice. > stpcpy() could halve performance in some cases (when the compiler inlines > and combines strcpy() and strlen() but doesn't do anything special with > stpcpy(), and inlining is good). Bruce hit the nail right on the head -- people are making assumptions with out know what their compiler is doing. Also, strcpy() and strlen() could easily be highly optimized ASM routines that together are still faster than a C stpcpy(). > > It actually may matter in some text-processing applications. Yes, BUT one should only use these non-standard functions AFTER they've actually done some profiling and see where the program is REALLY spending their time. -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 15:10:33 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 31E7F14CC5 for ; Sun, 31 Oct 1999 15:10:21 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA22452 for ; Mon, 1 Nov 1999 00:10:18 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA67820 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 00:10:17 +0100 (MET) Received: by hub.freebsd.org (Postfix, from userid 758) id 6387414CC5; Sun, 31 Oct 1999 15:10:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 54F011CD620; Sun, 31 Oct 1999 15:09:58 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Sun, 31 Oct 1999 15:09:58 -0800 (PST) From: Kris Kennaway To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: 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 Sun, 31 Oct 1999, Julian Elischer wrote: > ok, but can he do it after we have decided what we are trying to achieve? Sure :) Sorry for disturbing your discussion moderation.. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 15:15:48 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D6DCB14CC5 for ; Sun, 31 Oct 1999 15:15:26 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA22508 for ; Mon, 1 Nov 1999 00:15:19 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA67851 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 00:15:19 +0100 (MET) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 168C714EE1 for ; Sun, 31 Oct 1999 15:14:39 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40382>; Mon, 1 Nov 1999 10:09:16 +1100 Content-return: prohibited Date: Mon, 1 Nov 1999 10:13:35 +1100 From: Peter Jeremy Subject: Re: Storing small files in inodes In-reply-to: <19991029150228.BB45314BF7@hub.freebsd.org> To: freebsd-arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Nov1.100916est.40382@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <99Oct29.085056est.40332@border.alcanet.com.au> <19991029150228.BB45314BF7@hub.freebsd.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Oct-30 01:02:28 +1000, Jonathan M. Bresler wrote: >http://www.usenix.org/publications/library/proceedings/ana97/ganger.html > >With embedded inodes, the inodes for most files are stored in the >directory with the corresponding name, removing a physical level of >indirection without sacrificing the logical level of indirection. With >explicit grouping, the data blocks of multiple small files named by a >given directory are allocated adjacently and moved to and from the >disk as a unit in most cases. C-FFS is a more radical change than I was thinking of. By moving the inodes into the directory, it needs special handling for files don't have exactly 1 link. Also, from my reading of the paper, a small file still occupies a complete data block, it's just that the data block is `close to' the directory entry/inode for the file. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 15:44:59 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 71BC715060 for ; Sun, 31 Oct 1999 15:44:45 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA22685 for ; Mon, 1 Nov 1999 00:44:42 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA67928 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 00:44:42 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id C22B614D93 for ; Sun, 31 Oct 1999 15:40:33 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id QAA06808; Sun, 31 Oct 1999 16:40:28 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id QAA12893; Sun, 31 Oct 1999 16:40:27 -0700 Date: Sun, 31 Oct 1999 16:40:27 -0700 Message-Id: <199910312340.QAA12893@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: References: X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > ------------ Thread properties ----------- > 1/ Multiple independent 'threads of control' within a single process > at user level. The most basic quality of threads. > > 2/ Ability to simultaneously schedule two threads over separate > Processors. > > 3/ Inability of one thread to block aother thread unless they are > intentionally synchronising. I think this can be dropped, since it's both confusing and almost contradictory. There is no such way to 'block' a regular process, although one can stop it in Unix, so the issue of blocking implies a blocking on something, which is allowed. > 4/ All threads see the same address space (exactly). > > 5/ All threads share the same file resources. All threads share all the same resources (except for thread-specific stack). > 6/ (contentious) multiple theads should be bound to within the resource > limits of the single process. I'll leave that up to others if that's a good idea. > 7/ Some well documeted scheme exists for handling signals and othe rasync > events. I think this is one of the 'hard problems' to solve. > 8/ Exit/shutdown protocol is well defined. Agreed. > 9/ there exists a set of primatives that allow threads to influence the > in-process scheduling between themselves. Agreed, see #2. > 10/ your ideas here. Note, you an also suggest that I remove an idea. The ability for a process to have multiple threads active in the kernel (system calls) without stopping the process the threads are busy in. > It is notable that we already support Linux kernel threads on FreeBSD > better than we support a native threads model. This is because we support > the 'clone' system call through our rfork() code, and that is their basis > for threading. As is common for this group of people, we have not adopted > the Linux approach because it is considered to be 'too simplistic', > assigning a separate kernel schedulable process to run each thread. While I agree this 'simplistic' approach isn't as good as a N-M approach, it's certainly better than what we have now. Is anyone working on the more complex model *at all*, cause if not I'd like to see a simple kernel threading model used, cause something is better than nothing. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 15:49:44 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 5985314F0E for ; Sun, 31 Oct 1999 15:49:32 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA22740 for ; Mon, 1 Nov 1999 00:49:26 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA67967 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 00:49:26 +0100 (MET) Received: from arc.hq.cti.ru (arc.hq.cti.ru [195.34.40.3]) by hub.freebsd.org (Postfix) with ESMTP id A014814F0E for ; Sun, 31 Oct 1999 15:43:32 -0800 (PST) (envelope-from dima@tejblum.pp.ru) Received: (from uucp@localhost) by arc.hq.cti.ru (8.9.3/8.9.3) with UUCP id CAA10720; Mon, 1 Nov 1999 02:42:38 +0300 (MSK) (envelope-from dima@tejblum.pp.ru) Received: from tejblum.pp.ru (localhost [127.0.0.1]) by tejblum.pp.ru (8.9.3/8.9.3) with ESMTP id CAA02684; Mon, 1 Nov 1999 02:49:24 +0300 (MSK) (envelope-from dima@tejblum.pp.ru) Message-Id: <199910312349.CAA02684@tejblum.pp.ru> X-Mailer: exmh version 2.0gamma 1/27/96 To: obrien@NUXI.com Cc: Dmitrij Tejblum , freebsd-arch@freebsd.org From: Dmitrij Tejblum Subject: Re: stpcpy() In-reply-to: Your message of "Sun, 31 Oct 1999 14:50:49 PST." <19991031145049.A90745@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Nov 1999 02:49:24 +0300 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "David O'Brien" wrote: > On Sun, Oct 31, 1999 at 02:07:26PM +1100, Bruce Evans wrote: > > > Good stpcpy() could double performance in some cases. You would touch a > > > symbol once where you previously touched it twice. > > > stpcpy() could halve performance in some cases (when the compiler inlines > > and combines strcpy() and strlen() but doesn't do anything special with > > stpcpy(), and inlining is good). > > Bruce hit the nail right on the head -- people are making assumptions > with out know what their compiler is doing. You omitted following Bruce's words: > > In practice, gcc seems to only inline strlen(). At any rate, sptcpy() can be slower only if we are stupid enough or the compiler is really ancient/braindamaged. If the compiler inlines and combines strcpy() and strlen(), we can implement stpcpy() as static __inline char * stpcpy(char *__to, const char *__from) { return (strcpy(__to, __from) + strlen(__from)); } in string.h and make the compiler perform all the optimizations. > > Also, strcpy() and strlen() could easily be highly optimized ASM routines > that together are still faster than a C stpcpy(). There is nothing that prevent to clone the highly optimized ASM strcpy() to create a highly optimized ASM stpcpy(). > > > > It actually may matter in some text-processing applications. > > Yes, BUT one should only use these non-standard functions AFTER they've > actually done some profiling and see where the program is REALLY spending > their time. Really? Why? My colleagues use Windows and occasionally use stpcpy(), just because it is CONVENIENT and obviously cannot make their program slower. If the program is slower on FreeBSD (or even not compile), this is not their fault. The convenience is the main reason to add stpcpy() into libc. After the "-v" option was added to mkdir, the antibloat arguments became utterly nonsense. Dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 15:53:12 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3AA1014F7B for ; Sun, 31 Oct 1999 15:53:05 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA22793 for ; Mon, 1 Nov 1999 00:53:03 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA68027 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 00:53:03 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 1789F14F7B for ; Sun, 31 Oct 1999 15:45:18 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id SAA24146; Sun, 31 Oct 1999 18:44:02 -0500 (EST) Date: Sun, 31 Oct 1999 18:44:02 -0500 (EST) From: Daniel Eischen Message-Id: <199910312344.SAA24146@pcnet1.pcnet.com> To: freebsd-arch@freebsd.org, julian@whistle.com Subject: Re: Threads models and FreeBSD. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > ------------ Thread properties ----------- > 1/ Multiple independent 'threads of control' within a single process > at user level. The most basic quality of threads. > > 2/ Ability to simultaneously schedule two threads over separate > Processors. > > 3/ Inability of one thread to block aother thread unless they are > intentionally synchronising. > > 4/ All threads see the same address space (exactly). > > 5/ All threads share the same file resources. > > 6/ (contentious) multiple theads should be bound to within the resource > limits of the single process. > > 7/ Some well documeted scheme exists for handling signals and othe rasync > events. > > 8/ Exit/shutdown protocol is well defined. > > 9/ there exists a set of primatives that allow threads to influence the > in-process scheduling between themselves. In no order of importance: 10.) Quick access to curthread and thread specific data. We shouldn't have to enter the kernel to get this. This should also be true for threads spread across multiple [lightweight] processes. 11.) Ability for the threads library to cancel/terminate a thread blocked in the kernel. 12.) A libpthread that can be linked with libc. 13.) Libc needs to change so that library functions and system calls used internal to the library do not use the externally visible cancellable equivalents. Desired: 1.) Ability for the threads library to determine the scheduling model. This is one advantage of scheduler activations. The threads library is informed when a thread blocks or unblocks in the kernel and decides which thread runs next. This also solves the priority inversion locking problem (3/) because the threads library can determine if a swapped out thread was in a critical region. In this case, the thread is resumed on the next available LWP and can be made to yield immediately upon exiting the critical region. I guess this is more my desire, but what the heck ;) 2.) Ability for an application to bind a thread to a lightweight process as well as to a CPU. 3.) Ability to have M by N threads over processes, where M and N can be determined by the application. 4.) Ability for the application to specify one or more LWP-bound threads be run in a different scheduling class than the rest of the threads in the application. > What we have at the moment: > [...] > If you are going to say "support pthreads" I'd like you to instead break > that down to what we need to have in order to support pthreads.. I want > pthreads to be a by-product (almost) of a good threading model, not the > design goal. I really think that scheduler activations are the way to go instead of the LinuxThreads approach. I also think it's better than async call gates because the application can have explicit control of the number of LWPs and threads, and the threads library has total control of scheduling. Some basic kernel changes in order to support scheduler activations: o Modify the sleep queue to queue wait_node entities, not procs. A wait_node would consist of at least a boolean flag and a proc or thread pointer to support queueing of threads or procs. o Modify mi_switch to call mi_context_switch for a multi-threaded process. When a process blocks in the kernel, mi_context_switch saves the user and kernel context, switches to a predetermined kernel/user context and makes an upcall to the threads library notifying it of the event. The library returns with another thread to run. o Allow for maintaining (off proc) a queue of kernel contexts (at least one for each blocked thread, one for each currently running thread, and one for the upcall notification). The kernel context would consist of at least a kernel stack, kernel register set save area, and a pointer to the user-land ucontext/thread. You would also hang the list of LWPs off the parent proc, and be able to determine which LWPs are being used or not used. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 15:57:23 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 5722D1525F for ; Sun, 31 Oct 1999 15:57:15 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA22883 for ; Mon, 1 Nov 1999 00:57:10 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA68162 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 00:57:10 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id A04BB151B2 for ; Sun, 31 Oct 1999 15:54:46 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id SAA25110; Sun, 31 Oct 1999 18:53:30 -0500 (EST) Date: Sun, 31 Oct 1999 18:53:30 -0500 (EST) From: Daniel Eischen Message-Id: <199910312353.SAA25110@pcnet1.pcnet.com> To: julian@whistle.com, nate@mt.sri.com Subject: Re: Threads models and FreeBSD. Cc: freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > It is notable that we already support Linux kernel threads on FreeBSD > > better than we support a native threads model. This is because we support > > the 'clone' system call through our rfork() code, and that is their basis > > for threading. As is common for this group of people, we have not adopted > > the Linux approach because it is considered to be 'too simplistic', > > assigning a separate kernel schedulable process to run each thread. > > While I agree this 'simplistic' approach isn't as good as a N-M > approach, it's certainly better than what we have now. Is anyone > working on the more complex model *at all*, cause if not I'd like to see > a simple kernel threading model used, cause something is better than > nothing. Yes. Scheduler activations, but I will probably be needing some help in the kernel side of things. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 16: 3:51 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id E4C3B14E70 for ; Sun, 31 Oct 1999 16:03:38 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id BAA22994 for ; Mon, 1 Nov 1999 01:03:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA68276 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 01:03:36 +0100 (MET) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id B0F7B14E70 for ; Sun, 31 Oct 1999 16:03:11 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.9.3/8.9.3) id QAA15795; Sun, 31 Oct 1999 16:02:56 -0800 (PST) (envelope-from obrien) Date: Sun, 31 Oct 1999 16:02:55 -0800 From: "David O'Brien" To: Dmitrij Tejblum Cc: freebsd-arch@freebsd.org Subject: Re: stpcpy() Message-ID: <19991031160255.E2388@relay.nuxi.com> Reply-To: obrien@NUXI.com References: <19991031145049.A90745@dragon.nuxi.com> <199910312349.CAA02684@tejblum.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre1i In-Reply-To: <199910312349.CAA02684@tejblum.pp.ru> X-Operating-System: FreeBSD 3.3-STABLE Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Nov 01, 1999 at 02:49:24AM +0300, Dmitrij Tejblum wrote: > > Bruce hit the nail right on the head -- people are making assumptions > > with out know what their compiler is doing. > > You omitted following Bruce's words: > > > > In practice, gcc seems to only inline strlen(). What does that have to do with the wisdom I was extracting from BDE's statements? A LOT of people are trying to optimize things with out knowing what their compiler does. > There is nothing that prevent to clone the highly optimized ASM strcpy() > to create a highly optimized ASM stpcpy(). Except most application developers don't make you build a new libc to add an ASM file they provide. > Really? Why? My colleagues use Windows and occasionally use stpcpy(), > just because it is CONVENIENT and obviously cannot make their program > slower. If the program is slower on FreeBSD (or even not compile), this is > not their fault. Bull crap. If an application writer uses non-standard functions it *is* their fault. -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 16:52:35 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 5D9D214C24 for ; Sun, 31 Oct 1999 16:52:32 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id BAA23513 for ; Mon, 1 Nov 1999 01:52:31 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA68581 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 01:52:30 +0100 (MET) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id E193C15099 for ; Sun, 31 Oct 1999 16:51:59 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p08-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.137]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id JAA20773; Mon, 1 Nov 1999 09:51:49 +0900 (JST) Message-ID: <381CE369.C28FB9A3@newsguy.com> Date: Mon, 01 Nov 1999 09:48:41 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Nate Williams Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. References: <199910312340.QAA12893@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams wrote: > > > 3/ Inability of one thread to block aother thread unless they are > > intentionally synchronising. > > I think this can be dropped, since it's both confusing and almost > contradictory. There is no such way to 'block' a regular process, > although one can stop it in Unix, so the issue of blocking implies a > blocking on something, which is allowed. > > > 10/ your ideas here. Note, you an also suggest that I remove an idea. > > The ability for a process to have multiple threads active in the kernel > (system calls) without stopping the process the threads are busy in. This is a subset of the one you think can be dropped. :-) Maybe it should rather be reworded? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "People call him Neutron Star, 'cuz he's so dense lights bends around him." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 16:54:55 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id DA4CE14C24 for ; Sun, 31 Oct 1999 16:54:53 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id BAA23568 for ; Mon, 1 Nov 1999 01:54:52 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA68626 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 01:54:52 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 0E7D914C24 for ; Sun, 31 Oct 1999 16:54:46 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id RAA07461; Sun, 31 Oct 1999 17:54:44 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id RAA13342; Sun, 31 Oct 1999 17:54:43 -0700 Date: Sun, 31 Oct 1999 17:54:43 -0700 Message-Id: <199911010054.RAA13342@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Daniel C. Sobral" Cc: Nate Williams , Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: <381CE369.C28FB9A3@newsguy.com> References: <199910312340.QAA12893@mt.sri.com> <381CE369.C28FB9A3@newsguy.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > 3/ Inability of one thread to block aother thread unless they are > > > intentionally synchronising. > > > > I think this can be dropped, since it's both confusing and almost > > contradictory. There is no such way to 'block' a regular process, > > although one can stop it in Unix, so the issue of blocking implies a > > blocking on something, which is allowed. > > > > > 10/ your ideas here. Note, you an also suggest that I remove an idea. > > > > The ability for a process to have multiple threads active in the kernel > > (system calls) without stopping the process the threads are busy in. > > This is a subset of the one you think can be dropped. :-) Maybe it > should rather be reworded? I guess 'inability' implies that we don't to allow another process to effect another thread. The double negative is what confuses me. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 17: 9:37 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 533E814A1E for ; Sun, 31 Oct 1999 17:09:34 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id CAA24363 for ; Mon, 1 Nov 1999 02:09:33 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA68774 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 02:09:33 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 03A4114A1E for ; Sun, 31 Oct 1999 17:09:23 -0800 (PST) (envelope-from julian@whistle.com) Received: from home.elischer.org (home.elischer.org [207.76.204.203]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id RAA28419; Sun, 31 Oct 1999 17:09:18 -0800 (PST) Date: Sun, 31 Oct 1999 17:09:15 -0800 (PST) From: Julian Elischer X-Sender: julian@home.elischer.org To: Nate Williams Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: <199910312340.QAA12893@mt.sri.com> 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 Sun, 31 Oct 1999, Nate Williams wrote: > > ------------ Thread properties ----------- > > 1/ Multiple independent 'threads of control' within a single process > > at user level. The most basic quality of threads. > > > > 2/ Ability to simultaneously schedule two threads over separate > > Processors. > > > > 3/ Inability of one thread to block aother thread unless they are > > intentionally synchronising. > > I think this can be dropped, since it's both confusing and almost > contradictory. There is no such way to 'block' a regular process, > although one can stop it in Unix, so the issue of blocking implies a > blocking on something, which is allowed. What this means is that if one thread does a read() and blocks, the other threads don't all block. maybe I should reword it to: "Inability of one thread to unwittingly block another thread during normal operations" ? > > > 4/ All threads see the same address space (exactly). > > > > 5/ All threads share the same file resources. > > All threads share all the same resources (except for thread-specific stack). Well they can see all the other stacks, they just don't use them as the stack. How would you better word that? > > > 6/ (contentious) multiple theads should be bound to within the resource > > limits of the single process. > > I'll leave that up to others if that's a good idea. It's certainly something to be optioanlly allowed if not by default, otherwise 100 threads can allow a single process to hog an entire system. > > > 7/ Some well documeted scheme exists for handling signals and other > > async events. > > I think this is one of the 'hard problems' to solve. As one of the "hard problems" it's received lot of work. Who has done some reading on this topic? > > 8/ Exit/shutdown protocol is well defined. > > Agreed. > > > 9/ there exists a set of primatives that allow threads to influence the > > in-process scheduling between themselves. > > Agreed, see #2. > > > 10/ your ideas here. Note, you an also suggest that I remove an idea. > > The ability for a process to have multiple threads active in the kernel > (system calls) without stopping the process the threads are busy in. This is the one I had as #3 that you objected to. Obviously I need to work on the wording.. And of course having multiple treads ACTIVE in the kernel is a different (SMP) project.. Obviously a thread runs within the kernel without being pre-empted by the userland thread scheduler, so that all but one of the threads in the kernel must be sleeping. > > > It is notable that we already support Linux kernel threads on FreeBSD > > better than we support a native threads model. This is because we support > > the 'clone' system call through our rfork() code, and that is their basis > > for threading. As is common for this group of people, we have not adopted > > the Linux approach because it is considered to be 'too simplistic', > > assigning a separate kernel schedulable process to run each thread. > > While I agree this 'simplistic' approach isn't as good as a N-M > approach, it's certainly better than what we have now. Is anyone > working on the more complex model *at all*, cause if not I'd like to see > a simple kernel threading model used, cause something is better than > nothing. Richard seaman's work is available. it can be used prety much without change.. Do we want to do that? I think the libc_r guys should be left to make that decision, but possibly having a simple underlying mechanism now while we work on the better one might be good idea.... but this is getting ahead of our selves.. let's get the requirements down first.. I will repost a modilfied version of the requirements in a second incorporating suggestions. julian > > > > Nate > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 17:16: 5 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 54D8B14A1E for ; Sun, 31 Oct 1999 17:16:01 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id CAA24680 for ; Mon, 1 Nov 1999 02:16:01 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA68846 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 02:16:00 +0100 (MET) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id BF9AD14A1E for ; Sun, 31 Oct 1999 17:15:50 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40343>; Mon, 1 Nov 1999 12:10:26 +1100 Content-return: prohibited Date: Mon, 1 Nov 1999 12:15:41 +1100 From: Peter Jeremy Subject: Re: Threads models and FreeBSD. In-reply-to: To: freebsd-arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Nov1.121026est.40343@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [This should have gone to the list, not just Julian] On 1999-Nov-01 08:15:23 +1100, Julian Elischer wrote: >So what are the definitions that a thread enabled environment should >possess? One good starting point would be some agreement on terminology since /usr/include/sys/proc.h states: * This structure contains the information needed to manage a thread of * control, known in UN*X as a process; For the purposes of this discussion, I suggest that `process' refers to 1 or more threads sharing a common address space. This is distinct from the usage within 4.4BSD - particularly rfork(2). >2/ Ability to simultaneously schedule two threads over separate >Processors. ^^^ N ^ N >6/ (contentious) multiple theads should be bound to within the resource >limits of the single process. Whilst some of this is `implementation' rather than `requirements', a good place to start is to work through each field in struct proc and decide whether that information relates to the process as a whole, or a single thread. (This will need to be done at some stage, and is a good trigger for deciding what differentiates a thread from a process). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 17:16:37 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id AF97214A1E for ; Sun, 31 Oct 1999 17:16:32 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id CAA24691 for ; Mon, 1 Nov 1999 02:16:31 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA68868 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 02:16:31 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 2817B14A1E for ; Sun, 31 Oct 1999 17:16:20 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id SAA07652; Sun, 31 Oct 1999 18:16:19 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id SAA13482; Sun, 31 Oct 1999 18:16:19 -0700 Date: Sun, 31 Oct 1999 18:16:19 -0700 Message-Id: <199911010116.SAA13482@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: Nate Williams , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: References: <199910312340.QAA12893@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > 3/ Inability of one thread to block aother thread unless they are > > > intentionally synchronising. > > > > I think this can be dropped, since it's both confusing and almost > > contradictory. There is no such way to 'block' a regular process, > > although one can stop it in Unix, so the issue of blocking implies a > > blocking on something, which is allowed. > > What this means is that if one thread does a read() and blocks, the other > threads don't all block. > > maybe I should reword it to: > "Inability of one thread to unwittingly block another thread during normal > operations" ? How about the abilty for multiple threads to execute at the same time? :) The double negative implies that we would not add functionality that might be desired. > > > 4/ All threads see the same address space (exactly). > > > > > > 5/ All threads share the same file resources. > > > > All threads share all the same resources (except for thread-specific stack). > Well they can see all the other stacks, they just don't use them as the > stack. How would you better word that? The resources are *all* shared (not just file resources), but each thread has it's own thread-specific stack. > Richard seaman's work is available. it can be used prety much without > change.. Do we want to do that? Who's we white-man? (That's a very American joke for our international readers). I'd like to here from the 'kernel architects', who have been completely silent on the topic of kernel threads up til this point. (And not just in the context of this discussion, they've been mostly silent for months, if not years on this topic, except to say that they don't like Richard's solution..) Another thing I'd like to add to the requirements list is that the threads use 'standard' threading mechanisms for safety, such as mutex/semaphore, etc.., which should exist in the kernel as well. This is inline with the Posix stuff, and rather than invent our 'own' new kind of data structure, I'd like to stick with known solutions that work and everyone for the most part understands. Howeer, that requirement may be more detailed oriented than what you are looking for now. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 17:42:14 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 9BF0814C01 for ; Sun, 31 Oct 1999 17:42:11 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id CAA27561 for ; Mon, 1 Nov 1999 02:42:11 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA69085 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 02:42:10 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 04B8114C01 for ; Sun, 31 Oct 1999 17:41:41 -0800 (PST) (envelope-from julian@whistle.com) Received: from home.elischer.org (home.elischer.org [207.76.204.203]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id RAA29024; Sun, 31 Oct 1999 17:41:38 -0800 (PST) Date: Sun, 31 Oct 1999 17:41:35 -0800 (PST) From: Julian Elischer X-Sender: julian@home.elischer.org To: Daniel Eischen Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: <199910312344.SAA24146@pcnet1.pcnet.com> 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 Sun, 31 Oct 1999, Daniel Eischen wrote: > > ------------ Thread properties ----------- > > 1/ Multiple independent 'threads of control' within a single process > > at user level. The most basic quality of threads. > > > > 2/ Ability to simultaneously schedule two threads over separate > > Processors. > > > > 3/ Inability of one thread to block aother thread unless they are > > intentionally synchronising. > > > > 4/ All threads see the same address space (exactly). > > > > 5/ All threads share the same file resources. > > > > 6/ (contentious) multiple theads should be bound to within the resource > > limits of the single process. > > > > 7/ Some well documeted scheme exists for handling signals and othe rasync > > events. > > > > 8/ Exit/shutdown protocol is well defined. > > > > 9/ there exists a set of primatives that allow threads to influence the > > in-process scheduling between themselves. > > In no order of importance: > > 10.) Quick access to curthread and thread specific data. We shouldn't > have to enter the kernel to get this. This should also be true > for threads spread across multiple [lightweight] processes. > fair enough.. (though very much a 'request' than a major design goal) > 11.) Ability for the threads library to cancel/terminate a thread > blocked in the kernel. oooooh > > 12.) A libpthread that can be linked with libc. At this stage, an implementation detail, can I leave this till a later stage? > > 13.) Libc needs to change so that library functions and system calls > used internal to the library do not use the externally visible > cancellable equivalents. I see I need to start a 'user-land properties' list. > > Desired: > > 1.) Ability for the threads library to determine the scheduling model. > This is one advantage of scheduler activations. The threads library > is informed when a thread blocks or unblocks in the kernel and > decides which thread runs next. This also solves the priority > inversion locking problem (3/) because the threads library can > determine if a swapped out thread was in a critical region. In > this case, the thread is resumed on the next available LWP and > can be made to yield immediately upon exiting the critical region. > I guess this is more my desire, but what the heck ;) Can you look a tteh re-written goals (posted soon) and try express this more simply? > > 2.) Ability for an application to bind a thread to a lightweight > process as well as to a CPU. > > 3.) Ability to have M by N threads over processes, where M and N > can be determined by the application. > > 4.) Ability for the application to specify one or more LWP-bound > threads be run in a different scheduling class than the rest > of the threads in the application. > > > What we have at the moment: > > > [...] > > If you are going to say "support pthreads" I'd like you to instead break > > that down to what we need to have in order to support pthreads.. I want > > pthreads to be a by-product (almost) of a good threading model, not the > > design goal. > > I really think that scheduler activations are the way to go instead > of the LinuxThreads approach. I also think it's better than async > call gates because the application can have explicit control of the > number of LWPs and threads, and the threads library has total control > of scheduling. > > Some basic kernel changes in order to support scheduler activations: [...] Very nice but you're jumping the gun here.. > > Dan Eischen > eischen@vigrid.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 17:49:53 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id DAB0214C01 for ; Sun, 31 Oct 1999 17:49:51 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id CAA28306 for ; Mon, 1 Nov 1999 02:49:50 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA69115 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 02:49:50 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 575CA14C01 for ; Sun, 31 Oct 1999 17:49:42 -0800 (PST) (envelope-from julian@whistle.com) Received: from home.elischer.org (home.elischer.org [207.76.204.203]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id RAA29219; Sun, 31 Oct 1999 17:49:37 -0800 (PST) Date: Sun, 31 Oct 1999 17:49:34 -0800 (PST) From: Julian Elischer X-Sender: julian@home.elischer.org To: Nate Williams Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: <199911010116.SAA13482@mt.sri.com> 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 Sun, 31 Oct 1999, Nate Williams wrote: > > > > 3/ Inability of one thread to block aother thread unless they are > > > > intentionally synchronising. > > > > > > I think this can be dropped, since it's both confusing and almost > > > contradictory. There is no such way to 'block' a regular process, > > > although one can stop it in Unix, so the issue of blocking implies a > > > blocking on something, which is allowed. > > > > What this means is that if one thread does a read() and blocks, the other > > threads don't all block. > > > > maybe I should reword it to: > > "Inability of one thread to unwittingly block another thread during normal > > operations" ? > > How about the abilty for multiple threads to execute at the same time? > :) well that requires multiple processors.. see #2 maybe I need to make it more explicit? > > The double negative implies that we would not add functionality that > might be desired. > > > > > 4/ All threads see the same address space (exactly). > > > > > > > > 5/ All threads share the same file resources. > > > > > > All threads share all the same resources (except for thread-specific stack). > > Well they can see all the other stacks, they just don't use them as the > > stack. How would you better word that? > > The resources are *all* shared (not just file resources), but each > thread has it's own thread-specific stack. ok gimme a better wording.. yours leads me to wonder if there is somethign special about the mamory a particular thread's stack is on.. (they don't share processor registers BTW, nor do they neccesarily share proccessors if they have affinity) > > > Richard seaman's work is available. it can be used prety much without > > change.. Do we want to do that? > > Another thing I'd like to add to the requirements list is that the > threads use 'standard' threading mechanisms for safety, such as > mutex/semaphore, etc.., which should exist in the kernel as well. > > This is inline with the Posix stuff, and rather than invent our 'own' > new kind of data structure, I'd like to stick with known solutions that > work and everyone for the most part understands. > > Howeer, that requirement may be more detailed oriented than what you are > looking for now. yes, though maybe a meta-goal of 'be able to support all pthreads functtionality' is a good idea. > > > > Nate > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 18:17:28 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 5ED6614BD7 for ; Sun, 31 Oct 1999 18:17:18 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA00987 for ; Mon, 1 Nov 1999 03:17:17 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA69255 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 03:17:16 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 1975614BD7 for ; Sun, 31 Oct 1999 18:16:49 -0800 (PST) (envelope-from julian@whistle.com) Received: from home.elischer.org (home.elischer.org [207.76.204.203]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id SAA30144; Sun, 31 Oct 1999 18:16:45 -0800 (PST) Date: Sun, 31 Oct 1999 18:16:43 -0800 (PST) From: Julian Elischer X-Sender: julian@home.elischer.org To: Nate Williams Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: <199911010158.SAA13775@mt.sri.com> 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 Sun, 31 Oct 1999, Nate Williams wrote: > > > > maybe I should reword it to: > > > > "Inability of one thread to unwittingly block another thread during normal > > > > operations" ? > > > > > > How about the abilty for multiple threads to execute at the same time? > > > :) > > well that requires multiple processors.. > > > > see #2 > > maybe I need to make it more explicit? > > > > It's the 'inability to block' that gets me. see new improved wording to follow > > > > > > > 4/ All threads see the same address space (exactly). > > > > > > > > > > > > 5/ All threads share the same file resources. > > > > > > > > > > All threads share all the same resources (except for thread-specific stack). > > > > Well they can see all the other stacks, they just don't use them as the > > > > stack. How would you better word that? > > > > > > The resources are *all* shared (not just file resources), but each > > > thread has it's own thread-specific stack. > > > > ok gimme a better wording.. yours leads me to wonder if there is > > somethign special about the mamory a particular thread's stack is on.. > > That's the only thing that is not 'shared' across threads. Everything > else is shared. but that's wrong.. the memory is shared.. only the %sp register is differnet.. > > > (they don't share processor registers BTW, nor do they neccesarily share > > proccessors if they have affinity) > > That's an implementation issue. I think most clued folks will > understand that registers aren't shared, although in some cases they > might be. :) > > > > Nate > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 18:18:46 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id B11A714BD7 for ; Sun, 31 Oct 1999 18:18:43 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA01172 for ; Mon, 1 Nov 1999 03:18:43 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA69277 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 03:18:42 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 78B1B14BD7 for ; Sun, 31 Oct 1999 18:18:33 -0800 (PST) (envelope-from julian@whistle.com) Received: from home.elischer.org (home.elischer.org [207.76.204.203]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id SAA30159 for ; Sun, 31 Oct 1999 18:18:31 -0800 (PST) Date: Sun, 31 Oct 1999 18:18:29 -0800 (PST) From: Julian Elischer X-Sender: julian@home.elischer.org To: freebsd-arch@freebsd.org Subject: Threads goals version II 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 ---Possible system design goals of system threads support -- --- Note just becasue something is in this list doesn't mean that it will be done, just that it's going o be carried forward to further discussion. -------------------------------------------------------------- 1/ Multiple independent 'threads of control' within a single process at user level. The most basic quality of threads. 2/ Ability to simultaneously schedule M threads over N Processors. 2A/ ability to tune and control the above.. 3/ One blocking thread cannot block another thread. Blocking of one thread does not imply that other threads be blocked. 4/ All threads see the same address space (exactly). 5/ All threads share the same file resources. 6/ (contentious) multiple theads should be bound to within the resource limits of the single process. 7/ Some well documeted scheme exists for handling signals and othe rasync events. 8/ Exit/shutdown protocol is well defined. 9/ there exists a set of primatives that allow threads to influence the in-process scheduling between themselves. 10/ Quick access to curthread and thread specific data. We shouldn't have to enter the kernel to get this. This should also be true for threads spread across multiple [lightweight] processes. 11/ Ability for the threads library to cancel/terminate a thread blocked in the kernel. 12/ Processorr affinity for threads. 13/ Thread scheduling classes. 13A/ Assigned 'per thread' 14/ your goals here.. ---- possible userland implementation goals----- 1/ A libpthread that can be linked with libc. 2/ Libc needs to change so that library functions and system calls used internal to the library do not use the externally visible cancellable equivalents. 3/ your goals here.. ------------- refs: http://www.freebsd.org/~deischen/p95-anderson.pdf http://www.freebsd.org/cgi/getmsg.cgi?fetch=25000+30231+/usr/local/www/db/text/1 999/freebsd-current/19990321.freebsd-current http://lt.tar.com/ ------------------------------------- the players, Note these are just people who have exhibited either code or knowledge of the literature at this point. Terry Lambert Daniel Eischen John Birrell Richard Seaman Amancio Hasty Jake Burkholder Chris Csanady Kris Kennaway To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 18:19:49 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 1FFF114E9E for ; Sun, 31 Oct 1999 18:19:45 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA01205 for ; Mon, 1 Nov 1999 03:19:44 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA69298 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 03:19:44 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 59C7514BD7 for ; Sun, 31 Oct 1999 18:19:29 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id TAA08245; Sun, 31 Oct 1999 19:19:26 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id TAA13936; Sun, 31 Oct 1999 19:19:25 -0700 Date: Sun, 31 Oct 1999 19:19:25 -0700 Message-Id: <199911010219.TAA13936@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: Daniel Eischen , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: References: <199910312344.SAA24146@pcnet1.pcnet.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 11.) Ability for the threads library to cancel/terminate a thread > > blocked in the kernel. > > oooooh Oooh is right. This has the potential to deadlock the kernel if the thread owns some sort of 'thread' resources. Justin and I were having a discussion about this very thing earlier today, and I don't think I was able to express myself well, so here it goes again. Basically, what happens if a particular thread owns a resource that others are blocking on, and it's woken up 'prematurely'? If the thread is aborted out of the kernel, the other threads (which might exist in the kernel) may not be woken up (ever), thus causing zombie threads. If you take this further, it's possible that you can introduce deadlock and/or races very easily when you allow threads to be aborted. Unfortunately, I'm all too familiar with this problem, having been able to design a system that all too often exhibits this behavior. :) What we did was move away from allowing a thread to aborted prematurely, and made all of our threads check for the existence of a 'aborted' flag. The downside to this is that if the thread is blocked, it will never wake up *unless* you know which resource it's blocked on, at which point you're back to square one. If we had a basic 'interrupt if blocked' mechanism in the threading primitives it might work, such that every thread would be allowed to 'unblock' just to check the flag, but for no other (abnormal) reason. This solution also has an added advantage in that the thread knows the exact context that it was 'aborted' at, and can do proper context saving and/or exception handling based on where it was at, rather than trying to guess at what went wrong. In pigin-Java. thread_start() { // Do the deed // Aquire lock synchronized (mutex) { try { block_waiting_for_something(); } catch (InterruptedException e) { // Someone is trying to get my attention. if (aborted) { // *Sigh* - And I really liked doing this... } return; } // Got whatever something I needed, deal with it.. try { block_waiting_for_something_else(); } catch (InterruptedException e) { // Someone is trying to get my attention. if (aborted) { // *Sigh* - And I really liked doing this... } return; } // Etc.... } I can deal with each blocked resource as necessary, or group them together if it makes more sense... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 18:21:34 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3327B14BD7 for ; Sun, 31 Oct 1999 18:21:31 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA01229 for ; Mon, 1 Nov 1999 03:21:30 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA69330 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 03:21:30 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 3BDA914BD7 for ; Sun, 31 Oct 1999 18:21:22 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id TAA08275; Sun, 31 Oct 1999 19:21:21 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id TAA13961; Sun, 31 Oct 1999 19:21:20 -0700 Date: Sun, 31 Oct 1999 19:21:20 -0700 Message-Id: <199911010221.TAA13961@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: Nate Williams , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: References: <199911010158.SAA13775@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > ok gimme a better wording.. yours leads me to wonder if there is > > > somethign special about the mamory a particular thread's stack is on.. > > > > That's the only thing that is not 'shared' across threads. Everything > > else is shared. > > but that's wrong.. the memory is shared.. > only the %sp register is differnet.. Right, my bad. Here's what I wrote to Sean. Thread share everything that a normal process, including a thread-specific stack which is used to keep each thread's context seperate from one another. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 18:26:53 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D454F153A6 for ; Sun, 31 Oct 1999 18:26:34 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA01282 for ; Mon, 1 Nov 1999 03:26:33 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA69372 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 03:26:33 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 73BA614D57 for ; Sun, 31 Oct 1999 18:25:33 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id TAA08315; Sun, 31 Oct 1999 19:25:33 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id TAA14010; Sun, 31 Oct 1999 19:25:32 -0700 Date: Sun, 31 Oct 1999 19:25:32 -0700 Message-Id: <199911010225.TAA14010@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads goals version II In-Reply-To: References: X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > ---Possible system design goals of system threads support -- > --- Note just becasue something is in this list doesn't mean that > it will be done, just that it's going o be carried forward to > further discussion. > -------------------------------------------------------------- > > 1/ Multiple independent 'threads of control' within a single process > at user level. The most basic quality of threads. > > 2/ Ability to simultaneously schedule M threads over N Processors. > 2A/ ability to tune and control the above.. > > 3/ One blocking thread cannot block another thread. > Blocking of one thread does not imply that other threads be > blocked. How about instead of 'cannot' we use the word 'does not necessarily' block another thread, and then append 'unless it does using programatic means'. Cannot implies some sort of bad thing. > 4/ All threads see the same address space (exactly). I like this. > 5/ All threads share the same file resources. How about 'process' resources instead? It's more than files that they share... > 10/ Quick access to curthread and thread specific data. We shouldn't > have to enter the kernel to get this. This should also be true > for threads spread across multiple [lightweight] processes. The last sentence is redundant, since threads are by definition lightweight processes. :) > 11/ Ability for the threads library to cancel/terminate a thread > blocked in the kernel. See previous email. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 18:33:53 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C21231509C for ; Sun, 31 Oct 1999 18:33:45 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA01392 for ; Mon, 1 Nov 1999 03:33:45 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA69468 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 03:33:44 +0100 (MET) Received: from rah.star-gate.com (216-200-29-190.snj0.flashcom.net [216.200.29.194]) by hub.freebsd.org (Postfix) with ESMTP id 93DBC15030 for ; Sun, 31 Oct 1999 18:33:33 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.3/8.8.8) with ESMTP id SAA10688; Sun, 31 Oct 1999 18:32:08 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199911010232.SAA10688@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: nate@mt.sri.com (Nate Williams) Cc: Julian Elischer , Daniel Eischen , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-reply-to: Your message of "Sun, 31 Oct 1999 19:19:25 MST." <199911010219.TAA13936@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 31 Oct 1999 18:32:08 -0800 From: Amancio Hasty Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate , Julian is a kernel thread kind of guy for quite some time. He ported the original scsi subsystem from Mach and for a long time he has been trying to bring in kernel threads to FreeBSD . So Julian how long have you been waiting for the right movement? 8) -- Amancio Hasty hasty@rah.star-gate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 18:45:34 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2558F14ECA for ; Sun, 31 Oct 1999 18:45:31 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA01532 for ; Mon, 1 Nov 1999 03:45:31 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA69564 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 03:45:30 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id D63D614ECA for ; Sun, 31 Oct 1999 18:45:25 -0800 (PST) (envelope-from julian@whistle.com) Received: from home.elischer.org (home.elischer.org [207.76.204.203]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id SAA30671; Sun, 31 Oct 1999 18:45:21 -0800 (PST) Date: Sun, 31 Oct 1999 18:45:18 -0800 (PST) From: Julian Elischer X-Sender: julian@home.elischer.org To: Nate Williams Cc: Daniel Eischen , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: <199911010219.TAA13936@mt.sri.com> 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 Sun, 31 Oct 1999, Nate Williams wrote: > > > 11.) Ability for the threads library to cancel/terminate a thread > > > blocked in the kernel. > > > > oooooh > > Oooh is right. This has the potential to deadlock the kernel if the > thread owns some sort of 'thread' resources. Justin and I were having a > discussion about this very thing earlier today, and I don't think I was > able to express myself well, so here it goes again. > > Basically, what happens if a particular thread owns a resource that > others are blocking on, and it's woken up 'prematurely'? If the thread > is aborted out of the kernel, the other threads (which might exist in > the kernel) may not be woken up (ever), thus causing zombie threads. I think what is being asked for is the thread version of the signal catching capabilities of the present tsleep(). The situation is no worse than it is at present. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 18:57: 4 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2DB0C14DF5 for ; Sun, 31 Oct 1999 18:57:01 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA01601 for ; Mon, 1 Nov 1999 03:57:00 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA69597 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 03:57:00 +0100 (MET) Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 98F3414DF5 for ; Sun, 31 Oct 1999 18:56:54 -0800 (PST) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id VAA04365; Sun, 31 Oct 1999 21:55:59 -0500 (EST) (envelope-from chuckr@picnic.mat.net) Date: Sun, 31 Oct 1999 21:55:59 -0500 (EST) From: Chuck Robey To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads goals version II In-Reply-To: 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 Sun, 31 Oct 1999, Julian Elischer wrote: > 7/ Some well documeted scheme exists for handling signals and other async > events. Would this possibly mean that if a signal isn't caught, it's action reflects upon the entire process, but if it's caught, a thread-specific handler catches it? That would mean that the kernel is going to have to be able to identify, when a signal comes in, both a process ID and (because a signal may post against other than the active process, such as a timer signal) a thread ID. Or would an uncaught signal merely act on the active thread? > 10/ Quick access to curthread and thread specific data. We shouldn't > have to enter the kernel to get this. This should also be true > for threads spread across multiple [lightweight] processes. This is the my question (the other was an outgrowth), I guess, which is, would /proc be modified, and then would ps report both on processes *and* threads (maybe sorted, the make more sense)? > 11/ Ability for the threads library to cancel/terminate a thread > blocked in the kernel. > > 12/ Processorr affinity for threads. It seems to me that it would be pretty likely that a thread would want to bias this choice itself. This is pretty closely identified with items 13 and 13A, isn't it? I would be pretty surprised if significantly better programs couldn't be written if a program could set it's own bias here. If each thread could be given it's own small block of kernel data, then I think that the rest could be done, right? Are we trying to find a way to do this with minimal kernel resources, is that it? ---------------------------------------------------------------------------- Chuck Robey | Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770 | I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 18:59:37 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 1B9CB14FFD for ; Sun, 31 Oct 1999 18:59:34 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA01623 for ; Mon, 1 Nov 1999 03:59:30 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA69619 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 03:59:30 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 6D2F5150A7 for ; Sun, 31 Oct 1999 18:59:05 -0800 (PST) (envelope-from julian@whistle.com) Received: from home.elischer.org (home.elischer.org [207.76.204.203]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id SAA30861; Sun, 31 Oct 1999 18:59:02 -0800 (PST) Date: Sun, 31 Oct 1999 18:58:59 -0800 (PST) From: Julian Elischer X-Sender: julian@home.elischer.org To: Nate Williams Cc: freebsd-arch@freebsd.org Subject: Re: Threads goals version II In-Reply-To: <199911010225.TAA14010@mt.sri.com> 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 Sun, 31 Oct 1999, Nate Williams wrote: > > ---Possible system design goals of system threads support -- > > --- Note just becasue something is in this list doesn't mean that > > it will be done, just that it's going o be carried forward to > > further discussion. > > -------------------------------------------------------------- > > > > 1/ Multiple independent 'threads of control' within a single process > > at user level. The most basic quality of threads. > > > > 2/ Ability to simultaneously schedule M threads over N Processors. > > 2A/ ability to tune and control the above.. > > > > 3/ One blocking thread cannot block another thread. > > Blocking of one thread does not imply that other threads be > > blocked. > > How about instead of 'cannot' we use the word 'does not necessarily' > block another thread, and then append 'unless it does using programatic > means'. > > Cannot implies some sort of bad thing. I'm trying to say that "just because one thread blocks, doesn't mean that the others can't keep running"! Will that do? > > > 4/ All threads see the same address space (exactly). > > I like this. > > > 5/ All threads share the same file resources. > > How about 'process' resources instead? It's more than files that they > share... 4/ All threads in a processs see the same address space (exactly). 5/ All threads in a process share the same system resources. > > 10/ Quick access to curthread and thread specific data. We shouldn't > > have to enter the kernel to get this. This should also be true > > for threads spread across multiple [lightweight] processes. > > The last sentence is redundant, since threads are by definition > lightweight processes. :) 10/ Quick access to curthread and thread specific data. > > > 11/ Ability for the threads library to cancel/terminate a thread > > blocked in the kernel. > > See previous email. See previous clarification.. :-) I think a way to ask a thread to 'wake up and back out' is what's required. > > > > Nate > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 19: 0:51 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 092361509F for ; Sun, 31 Oct 1999 19:00:48 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA01645 for ; Mon, 1 Nov 1999 04:00:47 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA69648 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 04:00:47 +0100 (MET) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id EA6BF1509F for ; Sun, 31 Oct 1999 19:00:16 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40379>; Mon, 1 Nov 1999 13:54:53 +1100 Content-return: prohibited Date: Mon, 1 Nov 1999 14:00:03 +1100 From: Peter Jeremy Subject: Re: Threads goals version II In-reply-to: To: freebsd-arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Nov1.135453est.40379@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Nov-01 13:18:29 +1100, Julian Elischer wrote: >2/ Ability to simultaneously schedule M threads over N Processors. and have Q (where Q = min(M,N)) threads simultaneously executing. >3/ One blocking thread cannot block another thread. > Blocking of one thread does not imply that other threads be >blocked. How about `a thread can remain runnable even if other threads in the process are blocked'. >12/ Processorr affinity for threads. There are two issues here: a) The SMP scheduler should maximise the probability that a thread will be re-scheduled onto the same CPU as last executed on. b) There should be a mechanism whereby a thread can optionally be restricted to only execute on a specified subset of the available CPUs. I believe that both of these are general SMP issues that should be covered in the next thread on your discussion list. The only impact for threads is that the affinity mechanism should have a thread, rather than process, granularity. >13/ Thread scheduling classes. > 13A/ Assigned 'per thread' This is basically point 9. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 19: 3:18 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 7540814E8B for ; Sun, 31 Oct 1999 19:03:14 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA01679 for ; Mon, 1 Nov 1999 04:03:14 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA69677 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 04:03:14 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 3D99D1509F for ; Sun, 31 Oct 1999 19:02:43 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id UAA08649; Sun, 31 Oct 1999 20:02:37 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id UAA14279; Sun, 31 Oct 1999 20:02:36 -0700 Date: Sun, 31 Oct 1999 20:02:36 -0700 Message-Id: <199911010302.UAA14279@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: Nate Williams , Daniel Eischen , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: References: <199911010219.TAA13936@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > 11.) Ability for the threads library to cancel/terminate a thread > > > > blocked in the kernel. > > > > > > oooooh > > > > Oooh is right. This has the potential to deadlock the kernel if the > > thread owns some sort of 'thread' resources. Justin and I were having a > > discussion about this very thing earlier today, and I don't think I was > > able to express myself well, so here it goes again. > > > > Basically, what happens if a particular thread owns a resource that > > others are blocking on, and it's woken up 'prematurely'? If the thread > > is aborted out of the kernel, the other threads (which might exist in > > the kernel) may not be woken up (ever), thus causing zombie threads. > > I think what is being asked for is the thread version of the > signal catching capabilities of the present tsleep(). > The situation is no worse than it is at present. Sort of, except that for every process you can only have one thread in kernel space, so the only deadlocks that can occur happen in userland, since the kernel has no primitives for doing 'synchronization' and notification. (Unless you consider the SysV stuff, but as we've seen, people tend to screw up using that as well. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 19: 3:40 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 4A33B14E8B for ; Sun, 31 Oct 1999 19:03:37 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA01690 for ; Mon, 1 Nov 1999 04:03:37 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA69699 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 04:03:36 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id DBE4B14E8B for ; Sun, 31 Oct 1999 19:03:31 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id WAA15579; Sun, 31 Oct 1999 22:02:16 -0500 (EST) Date: Sun, 31 Oct 1999 22:02:16 -0500 (EST) From: Daniel Eischen Message-Id: <199911010302.WAA15579@pcnet1.pcnet.com> To: julian@whistle.com, nate@mt.sri.com Subject: Re: Threads models and FreeBSD. Cc: eischen@vigrid.com, freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think what is being asked for is the thread version of the > signal catching capabilities of the present tsleep(). > The situation is no worse than it is at present. Exactly. If PCATCH isn't set, the cancel is deferred. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 19: 4:57 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 5239314E8B for ; Sun, 31 Oct 1999 19:04:54 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA01705 for ; Mon, 1 Nov 1999 04:04:54 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA69720 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 04:04:53 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id E8ABD14E8B for ; Sun, 31 Oct 1999 19:04:47 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id UAA08688; Sun, 31 Oct 1999 20:04:46 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id UAA14336; Sun, 31 Oct 1999 20:04:46 -0700 Date: Sun, 31 Oct 1999 20:04:46 -0700 Message-Id: <199911010304.UAA14336@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: peter.jeremy@alcatel.com.au Cc: freebsd-arch@freebsd.org Subject: Re: Threads goals version II In-Reply-To: <99Nov1.135453est.40379@border.alcanet.com.au> References: <99Nov1.135453est.40379@border.alcanet.com.au> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On 1999-Nov-01 13:18:29 +1100, Julian Elischer wrote: > >2/ Ability to simultaneously schedule M threads over N Processors. > and have Q (where Q = min(M,N)) threads simultaneously executing. > > >3/ One blocking thread cannot block another thread. > > Blocking of one thread does not imply that other threads be > >blocked. > > How about `a thread can remain runnable even if other threads in the > process are blocked'. FWIW, I like this wording. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 19: 9:18 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 9030514E8B for ; Sun, 31 Oct 1999 19:09:16 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA01759 for ; Mon, 1 Nov 1999 04:09:15 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA69772 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 04:09:15 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 37DED150D9 for ; Sun, 31 Oct 1999 19:09:09 -0800 (PST) (envelope-from julian@whistle.com) Received: from home.elischer.org (home.elischer.org [207.76.204.203]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id TAA31080 for ; Sun, 31 Oct 1999 19:09:07 -0800 (PST) Date: Sun, 31 Oct 1999 19:09:04 -0800 (PST) From: Julian Elischer X-Sender: julian@home.elischer.org To: freebsd-arch@freebsd.org Subject: Threads goals version III 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 ---Possible system design goals of system threads support -- --- Note just becasue something is in this list doesn't mean that it will be done, just that it's going o be carried forward to further discussion. -------------------------------------------------------------- 1/ Multiple independent 'threads of control' within a single process at user level. The most basic quality of threads. 2/ Ability to simultaneously schedule M threads over N Processors, and have min(M,N) threads simultaneously executing. 2A/ ability to tune and control the above.. 3/ just because one thread blocks, doesn't mean that the others can't keep running. 4/ All threads in a processs see the same address space (exactly). 5/ All threads in a process share the same system resources. 6/ (contentious) multiple theads should be bound to within the resource limits of the single process. 7/ Some well documeted scheme exists for handling signals and othe rasync events. 8/ Exit/shutdown protocol is well defined. 9/ there exists a set of primatives that allow threads to influence the in-process scheduling between themselves. 9A/ e.g. 'per thread' Thread scheduling classes. 10/ Quick access to curthread and thread specific data. 11/ A method to aks a thread blocked inthe kernel to wake up and back out. (similar to present 'signals') 12/ Processorr affinity for threads. ---- possible userland implementation goals----- 1/ A libpthread that can be linked with libc. 2/ Libc needs to change so that library functions and system calls used internal to the library do not use the externally visible cancellable equivalents. ------------- refs: http://www.freebsd.org/~deischen/p95-anderson.pdf http://www.freebsd.org/cgi/getmsg.cgi?fetch=25000+30231+/usr/local/www/db/text/1 999/freebsd-current/19990321.freebsd-current http://lt.tar.com/ ------------------------------------- the players, Note these are just people who have exhibited either code or knowledge of the literature at this point. Terry Lambert Daniel Eischen John Birrell Richard Seaman Amancio Hasty Jake Burkholder Chris Csanady Kris Kennaway To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 19:16:27 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 9D9A614E8B for ; Sun, 31 Oct 1999 19:16:23 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA01861 for ; Mon, 1 Nov 1999 04:16:22 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA69850 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 04:16:22 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 9D4E514E8B for ; Sun, 31 Oct 1999 19:16:16 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id WAA16785; Sun, 31 Oct 1999 22:15:01 -0500 (EST) Date: Sun, 31 Oct 1999 22:15:01 -0500 (EST) From: Daniel Eischen Message-Id: <199911010315.WAA16785@pcnet1.pcnet.com> To: eischen@vigrid.com, julian@whistle.com Subject: Re: Threads models and FreeBSD. Cc: freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > On Sun, 31 Oct 1999, Daniel Eischen wrote: [...] > > 10.) Quick access to curthread and thread specific data. We shouldn't > > have to enter the kernel to get this. This should also be true > > for threads spread across multiple [lightweight] processes. > > > fair enough.. (though very much a 'request' than a major design goal) Well, you could argue that a design that forced a system call whenever the current thread or TSD was needed was a bad design. I would imagine every pthread function needs to get at the current thread, so that would force at least one system call for each pthread call. > > 12.) A libpthread that can be linked with libc. > > At this stage, an implementation detail, can I leave this till a later > stage? OK Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 19:18:28 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A1B3114E8B for ; Sun, 31 Oct 1999 19:18:26 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA01887 for ; Mon, 1 Nov 1999 04:18:25 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA69877 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 04:18:25 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 482E014E8B for ; Sun, 31 Oct 1999 19:18:20 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id WAA17127; Sun, 31 Oct 1999 22:17:05 -0500 (EST) Date: Sun, 31 Oct 1999 22:17:05 -0500 (EST) From: Daniel Eischen Message-Id: <199911010317.WAA17127@pcnet1.pcnet.com> To: julian@whistle.com, nate@mt.sri.com Subject: Re: Threads models and FreeBSD. Cc: freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Another thing I'd like to add to the requirements list is that the > threads use 'standard' threading mechanisms for safety, such as > mutex/semaphore, etc.., which should exist in the kernel as well. > > This is inline with the Posix stuff, and rather than invent our 'own' > new kind of data structure, I'd like to stick with known solutions that > work and everyone for the most part understands. I agree 100% with this. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 19:34:17 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3E8D314A16 for ; Sun, 31 Oct 1999 19:34:14 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA02089 for ; Mon, 1 Nov 1999 04:34:14 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA70020 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 04:34:13 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id A3FB31563D for ; Sun, 31 Oct 1999 19:32:55 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id WAA18647; Sun, 31 Oct 1999 22:31:41 -0500 (EST) Date: Sun, 31 Oct 1999 22:31:41 -0500 (EST) From: Daniel Eischen Message-Id: <199911010331.WAA18647@pcnet1.pcnet.com> To: freebsd-arch@freebsd.org, julian@whistle.com Subject: Re: Threads goals version II Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 6/ (contentious) multiple theads should be bound to within the resource > limits of the single process. Multiple processes/LWPs should be allowed to have their own quantum and not count towards the [parent] process quantum, right? > 9/ there exists a set of primatives that allow threads to influence the > in-process scheduling between themselves. This should also be across multiple LWPs also. Perhaps we need to state our terminology - I'm not sure if this is what you meant. > 14/ your goals here.. The ability for the threads library to protect internal data structures to be safe from priority inversion problems when using multiple LWPs. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 19:43:16 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 38282151EC for ; Sun, 31 Oct 1999 19:42:58 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA02206 for ; Mon, 1 Nov 1999 04:42:56 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA70107 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 04:42:56 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id CF34014A16 for ; Sun, 31 Oct 1999 19:42:41 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id WAA19654; Sun, 31 Oct 1999 22:41:26 -0500 (EST) Date: Sun, 31 Oct 1999 22:41:26 -0500 (EST) From: Daniel Eischen Message-Id: <199911010341.WAA19654@pcnet1.pcnet.com> To: julian@whistle.com, nate@mt.sri.com Subject: Re: Threads goals version II Cc: freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 10/ Quick access to curthread and thread specific data. We shouldn't > > have to enter the kernel to get this. This should also be true > > for threads spread across multiple [lightweight] processes. > > The last sentence is redundant, since threads are by definition > lightweight processes. :) Well, that wasn't the intent. My use of lightweight process was to mean a process. I believe that threads and lightweight processes mean different things in Solaris. Reword it any way you see fit. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 19:49:10 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A374614ED2 for ; Sun, 31 Oct 1999 19:49:06 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA02284 for ; Mon, 1 Nov 1999 04:49:05 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA70187 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 04:49:05 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 0A34F155B6 for ; Sun, 31 Oct 1999 19:48:20 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id WAA20149; Sun, 31 Oct 1999 22:47:04 -0500 (EST) Date: Sun, 31 Oct 1999 22:47:04 -0500 (EST) From: Daniel Eischen Message-Id: <199911010347.WAA20149@pcnet1.pcnet.com> To: julian@whistle.com, nate@mt.sri.com Subject: Re: Threads models and FreeBSD. Cc: eischen@vigrid.com, freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I think what is being asked for is the thread version of the > > signal catching capabilities of the present tsleep(). > > The situation is no worse than it is at present. > > Sort of, except that for every process you can only have one thread in > kernel space, so the only deadlocks that can occur happen in > userland, since the kernel has no primitives for doing 'synchronization' > and notification. (Unless you consider the SysV stuff, but as we've > seen, people tend to screw up using that as well. :) No, I want to be able to have multiple threads in a single process be in kernel space. Only one can be running, but others can be blocked. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 19:57: 2 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 79C4A14D06 for ; Sun, 31 Oct 1999 19:56:54 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA02383 for ; Mon, 1 Nov 1999 04:56:53 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA70261 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 04:56:53 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 2A8FE1514A for ; Sun, 31 Oct 1999 19:56:41 -0800 (PST) (envelope-from julian@whistle.com) Received: from home.elischer.org (home.elischer.org [207.76.204.203]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id TAA32046; Sun, 31 Oct 1999 19:56:36 -0800 (PST) Date: Sun, 31 Oct 1999 19:56:34 -0800 (PST) From: Julian Elischer X-Sender: julian@home.elischer.org To: Daniel Eischen Cc: freebsd-arch@freebsd.org Subject: Re: Threads goals version II In-Reply-To: <199911010331.WAA18647@pcnet1.pcnet.com> 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 Sun, 31 Oct 1999, Daniel Eischen wrote: > > 6/ (contentious) multiple theads should be bound to within the resource > > limits of the single process. > > Multiple processes/LWPs should be allowed to have their own quantum and > not count towards the [parent] process quantum, right? Usually wrong.. usually the desired behaviour is to allow the multiple threads to share the resources (including processors) that are allocated to the process as a whole. If you are the only process running, your threads get to use 100& of cputime. If you are timesharing with 4 other people your threads get to share 20% of the cpu (on average). In reality you will do better than the otherrs as you won't be blocked as much as a single threaded process. I would think that the way to do this would be to expand the priority of the process as a whole and then let your own scheduler (within the process) decide which threads get the time. But that's implementation. do you really want wht you said? It's kind of hard to believe you really want that.. Unless you want to declare a set of kernel shedulable entities to be given their own scheduling group, which would be something you'd have to ask for explicitly. if all teh threads running in a process were doing some sort of 'continuation' scheme, then you migh tuse the 'rfork' schem to produce a second schedulable set of entities that didn't share with the first. (but now we're getting into implementation again.) > > > 9/ there exists a set of primatives that allow threads to influence the > > in-process scheduling between themselves. > > This should also be across multiple LWPs also. Perhaps we need to > state our terminology - I'm not sure if this is what you meant. There are processes. Processes own resources (including a share of the processor time). One process may have a number of kernel schedulable entities, or, stated backwards, a number of shedulable entities that share all their resources are grouped together as a single process. Then in user land there may be several threads of control. They may switch between themselves tranparently to the kernel. it is totally unaware of them. It knows only of the scedulable entities.. This is how I'm starting to envision things from what's been said so far. > > > 14/ your goals here.. > > The ability for the threads library to protect internal data structures > to be safe from priority inversion problems when using multiple LWPs. Priority inversion and inheritance within the userland scheduler.. > > Dan Eischen > eischen@vigrid.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 20:13: 4 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0133B15291 for ; Sun, 31 Oct 1999 20:12:50 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA02598 for ; Mon, 1 Nov 1999 05:12:50 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA70403 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 05:12:49 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id E595C14BD3 for ; Sun, 31 Oct 1999 20:12:36 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id VAA09451; Sun, 31 Oct 1999 21:12:34 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id VAA14975; Sun, 31 Oct 1999 21:12:32 -0700 Date: Sun, 31 Oct 1999 21:12:32 -0700 Message-Id: <199911010412.VAA14975@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Daniel Eischen Cc: julian@whistle.com, nate@mt.sri.com, freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: <199911010347.WAA20149@pcnet1.pcnet.com> References: <199911010347.WAA20149@pcnet1.pcnet.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > I think what is being asked for is the thread version of the > > > signal catching capabilities of the present tsleep(). > > > The situation is no worse than it is at present. > > > > Sort of, except that for every process you can only have one thread in > > kernel space, so the only deadlocks that can occur happen in > > userland, since the kernel has no primitives for doing 'synchronization' > > and notification. (Unless you consider the SysV stuff, but as we've > > seen, people tend to screw up using that as well. :) > > No, I want to be able to have multiple threads in a single process > be in kernel space. Only one can be running, but others can be > blocked. Agreed. My point is that if we allow multiple threads in a single process in the kernel space, it's alot worse than the present tsleep issues.... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 20:14:27 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0AD5B14BD3 for ; Sun, 31 Oct 1999 20:14:23 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA02627 for ; Mon, 1 Nov 1999 05:14:22 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA70430 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 05:14:22 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 6588814BD3 for ; Sun, 31 Oct 1999 20:13:49 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id VAA09465; Sun, 31 Oct 1999 21:13:48 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id VAA15024; Sun, 31 Oct 1999 21:13:47 -0700 Date: Sun, 31 Oct 1999 21:13:47 -0700 Message-Id: <199911010413.VAA15024@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Daniel Eischen Cc: freebsd-arch@freebsd.org, julian@whistle.com Subject: Re: Threads goals version II In-Reply-To: <199911010331.WAA18647@pcnet1.pcnet.com> References: <199911010331.WAA18647@pcnet1.pcnet.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 6/ (contentious) multiple theads should be bound to within the resource > > limits of the single process. > > Multiple processes/LWPs should be allowed to have their own quantum and > not count towards the [parent] process quantum, right? As I read that, no. A multi-threaded process shouldn't be given any more 'resources' than a single-threaded process. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 20:19:44 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 94D1315178 for ; Sun, 31 Oct 1999 20:19:38 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA02724 for ; Mon, 1 Nov 1999 05:19:37 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA70501 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 05:19:36 +0100 (MET) Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 95FAB15178 for ; Sun, 31 Oct 1999 20:19:17 -0800 (PST) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id XAA04920; Sun, 31 Oct 1999 23:18:17 -0500 (EST) (envelope-from chuckr@picnic.mat.net) Date: Sun, 31 Oct 1999 23:18:16 -0500 (EST) From: Chuck Robey To: Nate Williams Cc: Daniel Eischen , freebsd-arch@freebsd.org, julian@whistle.com Subject: Re: Threads goals version II In-Reply-To: <199911010413.VAA15024@mt.sri.com> 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 Sun, 31 Oct 1999, Nate Williams wrote: > > > 6/ (contentious) multiple theads should be bound to within the resource > > > limits of the single process. > > > > Multiple processes/LWPs should be allowed to have their own quantum and > > not count towards the [parent] process quantum, right? > > As I read that, no. A multi-threaded process shouldn't be given any > more 'resources' than a single-threaded process. With the notable exception that a multithreaded process must be able to be concurrently running on multiple processors simpultaneously, right? ---------------------------------------------------------------------------- Chuck Robey | Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770 | I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 20:22:34 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 920E115251 for ; Sun, 31 Oct 1999 20:22:18 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA02751 for ; Mon, 1 Nov 1999 05:22:18 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA70526 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 05:22:17 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id E7B6B14DAD for ; Sun, 31 Oct 1999 20:21:58 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id VAA09558; Sun, 31 Oct 1999 21:21:53 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id VAA15119; Sun, 31 Oct 1999 21:21:52 -0700 Date: Sun, 31 Oct 1999 21:21:52 -0700 Message-Id: <199911010421.VAA15119@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Chuck Robey Cc: Nate Williams , Daniel Eischen , freebsd-arch@freebsd.org, julian@whistle.com Subject: Re: Threads goals version II In-Reply-To: References: <199911010413.VAA15024@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > 6/ (contentious) multiple theads should be bound to within the resource > > > > limits of the single process. > > > > > > Multiple processes/LWPs should be allowed to have their own quantum and > > > not count towards the [parent] process quantum, right? > > > > As I read that, no. A multi-threaded process shouldn't be given any > > more 'resources' than a single-threaded process. > > With the notable exception that a multithreaded process must be able to be > concurrently running on multiple processors simpultaneously, right? I'm not sure. Once could argue that you get X% of the total CPU, which means that if you're normally allotted 20%, a single-threaded process would get 20% of a single CPU, and a threaded process might get 2x10% of each CPU (depending on whether or not the threads need to be on multiple CPU's, which may be the case.) It's an interesting problem.... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 20:33:16 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 5CB73151C9 for ; Sun, 31 Oct 1999 20:33:13 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA02984 for ; Mon, 1 Nov 1999 05:33:13 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA70672 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 05:33:12 +0100 (MET) Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 58E9A15350 for ; Sun, 31 Oct 1999 20:32:35 -0800 (PST) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id XAA05027; Sun, 31 Oct 1999 23:31:40 -0500 (EST) (envelope-from chuckr@picnic.mat.net) Date: Sun, 31 Oct 1999 23:31:40 -0500 (EST) From: Chuck Robey To: Nate Williams Cc: Daniel Eischen , freebsd-arch@freebsd.org, julian@whistle.com Subject: Re: Threads goals version II In-Reply-To: <199911010421.VAA15119@mt.sri.com> 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 Sun, 31 Oct 1999, Nate Williams wrote: > > > > > 6/ (contentious) multiple theads should be bound to within the resource > > > > > limits of the single process. > > > > > > > > Multiple processes/LWPs should be allowed to have their own quantum and > > > > not count towards the [parent] process quantum, right? > > > > > > As I read that, no. A multi-threaded process shouldn't be given any > > > more 'resources' than a single-threaded process. > > > > With the notable exception that a multithreaded process must be able to be > > concurrently running on multiple processors simpultaneously, right? > > I'm not sure. Once could argue that you get X% of the total CPU, which > means that if you're normally allotted 20%, a single-threaded process > would get 20% of a single CPU, and a threaded process might get 2x10% of > each CPU (depending on whether or not the threads need to be on multiple > CPU's, which may be the case.) > > It's an interesting problem.... I've been wondering what would be a practical minimum limit on the added information needed in kernel for kernel threads, and it seems that a count of runnable threads would be needed, and a count of thread blocks per quantum. If you had that, then you could see if there were just a few long running threads, and if a process was hogging processor time without any threads blocking, decrease the priority (like the present system). If there were a lot of blocks (much IO blockage) then I think I'd let the sucker go on, right? ---------------------------------------------------------------------------- Chuck Robey | Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770 | I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 20:44:46 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D40E114CAA for ; Sun, 31 Oct 1999 20:44:44 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA03077 for ; Mon, 1 Nov 1999 05:44:43 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA70723 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 05:44:43 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id BC47314CAA for ; Sun, 31 Oct 1999 20:44:37 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id XAA26092; Sun, 31 Oct 1999 23:43:22 -0500 (EST) Date: Sun, 31 Oct 1999 23:43:22 -0500 (EST) From: Daniel Eischen Message-Id: <199911010443.XAA26092@pcnet1.pcnet.com> To: eischen@vigrid.com, julian@whistle.com Subject: Re: Threads goals version II Cc: freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Multiple processes/LWPs should be allowed to have their own quantum and > > not count towards the [parent] process quantum, right? > > Usually wrong.. usually the desired behaviour is to allow the multiple > threads to share the resources (including processors) that are allocated > to the process as a whole. If you are the only process running, your > threads get to use 100& of cputime. > If you are timesharing with 4 other people your threads get to share 20% > of the cpu (on average). In reality you will do better than the otherrs > as you won't be blocked as much as a single threaded process. > > I would think that the way to do this would be to expand the priority of > the process as a whole and then let your own scheduler (within the > process) decide which threads get the time. > > But that's implementation. > > do you really want wht you said? It's kind of hard to believe you really > want that.. > Unless you want to declare a set of kernel shedulable entities to be > given their own scheduling group, which would be something you'd have to > ask for explicitly. > > if all teh threads running in a process were doing some sort of > 'continuation' scheme, then you migh tuse the 'rfork' schem to produce a > second schedulable set of entities that didn't share with the first. > (but now we're getting into implementation again.) What happens under LinuxThreads? I'd expect an rfork'd process to get an equal share of processor time as it's parent. If I create 10 threads with PTHREAD_SCOPE_SYSTEM, I expect to have 10 LWPs (or rfork'd processes). What I am trying to say is that an application that creates 10 threads with PTHREAD_SCOPE_SYSTEM gets more processor time than 8 threads with PTHREAD_SCOPE_SYSTEM and 2 threads with PTHREAD_SCOPE_PROCESS. > > The ability for the threads library to protect internal data structures > > to be safe from priority inversion problems when using multiple LWPs. > > Priority inversion and inheritance within the userland scheduler.. That's possible with scheduler activations, but not with something more like LinuxThreads. Under LinuxThreads, the threads library doesn't know when a thread has been swapped out, so if it owns a critical resource (let's say a spinlock), a higher priority thread wanting the same lock will spin continously and not let the other thread run. You have to push the locking mechanisms down into the kernel to solve this. I don't want the threads library to have to make a system call for internal library locking, but if you want a set of goals free from implementation, there it is... Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 20:53:32 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6EE5C15204 for ; Sun, 31 Oct 1999 20:53:29 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA03155 for ; Mon, 1 Nov 1999 05:53:29 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA70786 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 05:53:29 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 2813714CAA for ; Sun, 31 Oct 1999 20:53:23 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id XAA27063; Sun, 31 Oct 1999 23:52:08 -0500 (EST) Date: Sun, 31 Oct 1999 23:52:08 -0500 (EST) From: Daniel Eischen Message-Id: <199911010452.XAA27063@pcnet1.pcnet.com> To: eischen@vigrid.com, nate@mt.sri.com Subject: Re: Threads goals version II Cc: freebsd-arch@freebsd.org, julian@whistle.com Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Multiple processes/LWPs should be allowed to have their own quantum and > > not count towards the [parent] process quantum, right? > > As I read that, no. A multi-threaded process shouldn't be given any > more 'resources' than a single-threaded process. I differentiate between a thread created with PTHREAD_SCOPE_SYSTEM and PTHREAD_SCOPE_PROCESS. A thread with scope system contends for resources with all other threads in the same scheduling allocation domain relative to their system scheduling attributes...[POSIX standard]. I'd like to map PTHREAD_SCOPE_SYSTEM to the equivalent of an rfork. Dan Eishen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 20:55:24 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0255E15133 for ; Sun, 31 Oct 1999 20:55:21 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA03184 for ; Mon, 1 Nov 1999 05:55:20 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA70811 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 05:55:20 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 8887514FEA for ; Sun, 31 Oct 1999 20:55:13 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id XAA27221; Sun, 31 Oct 1999 23:53:57 -0500 (EST) Date: Sun, 31 Oct 1999 23:53:57 -0500 (EST) From: Daniel Eischen Message-Id: <199911010453.XAA27221@pcnet1.pcnet.com> To: eischen@vigrid.com, nate@mt.sri.com Subject: Re: Threads models and FreeBSD. Cc: freebsd-arch@freebsd.org, julian@whistle.com Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > No, I want to be able to have multiple threads in a single process > > be in kernel space. Only one can be running, but others can be > > blocked. > > Agreed. My point is that if we allow multiple threads in a single > process in the kernel space, it's alot worse than the present tsleep > issues.... Perhaps I haven't thought this through enough, but why? Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 21:28:25 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C634C1526D for ; Sun, 31 Oct 1999 21:27:57 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id GAA03470 for ; Mon, 1 Nov 1999 06:27:56 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA70928 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 06:27:55 +0100 (MET) Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id A280814BC4 for ; Sun, 31 Oct 1999 21:27:43 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id AAA04954 for ; Mon, 1 Nov 1999 00:22:59 -0500 (EST) Reply-To: Randell Jesup To: freebsd-arch@freebsd.org Subject: Re: stpcpy() References: <199910312349.CAA02684@tejblum.pp.ru> From: Randell Jesup Date: 01 Nov 1999 01:24:10 +0000 In-Reply-To: Dmitrij Tejblum's message of "Mon, 01 Nov 1999 02:49:24 +0300" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dmitrij Tejblum writes: >At any rate, stpcpy() can be slower only if we are stupid enough or >the compiler is really ancient/braindamaged. >> Also, strcpy() and strlen() could easily be highly optimized ASM routines >> that together are still faster than a C stpcpy(). > >There is nothing that prevent to clone the highly optimized ASM strcpy() >to create a highly optimized ASM stpcpy(). Quite true - in fact, stpcpy() is almost guaranteed to be as fast as strcpy, perhaps even faster if keeping the original pointer around causes a memory access and/or use of an extra register. (Minimal difference, of course - the real point is that it isn't slower, and it's trivial to implement as a modification of strcpy().) >> Yes, BUT one should only use these non-standard functions AFTER they've >> actually done some profiling and see where the program is REALLY spending >> their time. Sure, but why not code for efficiency to start with? Especially in such an obvious case. I'll bet 95% of programmers working on systems where stpcpy has been part of the libraries for a long time don't even know that it isn't standard. I don't know about you, but I code for systems where cutting CPU usage by 1% can actually make a real difference in the field and to costs. Perhaps this won't get me 1% - but a fraction of a percent here and another there adds up, and this is at truely zero cost. Other people will have applications where this might by more. >Really? Why? My colleagues use Windows and occasionally use stpcpy(), >just because it is CONVENIENT and obviously cannot make their program >slower. If the program is slower on FreeBSD (or even not compile), this is >not their fault. While non-ANSI standard, this particular function has been virtually standard in PC compilers for a Long Time. Like I said, near the start of this, probably for more than a decade it's been in every DOS/Win/Amiga/OS2/etc compiler I've used (unless my memory fails me, which it might). Why is there such vitriol being pointed at people who use a function that's been in every compiler they've ever had access to, can't hurt performance, could improve performance of heavily string-oriented apps, and is small? Quite honestly, I'd assumed that stpcpy() was in the library already. If I want strict ANSI, I'll tell the compiler that. I can't remember the last time I did that - I think it was when I was beta-testing commercial compilers 6 or 7 years ago. As for the bloat argument: Bloat in libraries is very different than bloat in executables; the impact is MUCH smaller. And as 'bloat' goes, this is about the most trivial example one could come up with. IMHO. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 22: 3:54 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 5A90114EDA for ; Sun, 31 Oct 1999 22:03:51 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id HAA03726 for ; Mon, 1 Nov 1999 07:03:50 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id HAA71019 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 07:03:49 +0100 (MET) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id AE10414EDA for ; Sun, 31 Oct 1999 22:03:42 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id XAA59666; Sun, 31 Oct 1999 23:03:41 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id XAA04972; Sun, 31 Oct 1999 23:05:45 -0700 (MST) Message-Id: <199911010605.XAA04972@harmony.village.org> To: Randell Jesup Subject: Re: stpcpy() Cc: freebsd-arch@freebsd.org In-reply-to: Your message of "01 Nov 1999 01:24:10 GMT." References: <199910312349.CAA02684@tejblum.pp.ru> Date: Sun, 31 Oct 1999 23:05:45 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Randell Jesup writes: : Sure, but why not code for efficiency to start with? Especially in : such an obvious case. I'll bet 95% of programmers working on systems where : stpcpy has been part of the libraries for a long time don't even know that : it isn't standard. I don't know about you, but I code for systems where : cutting CPU usage by 1% can actually make a real difference in the field : and to costs. Perhaps this won't get me 1% - but a fraction of a percent : here and another there adds up, and this is at truely zero cost. Other : people will have applications where this might by more. Premature sub-micro optimization. There is such a small benefit from this hack that it would rarely make the program run measurably faster. It is a small win, but does cause other problems with breaks standards conformimg programs. For example, the following program is strictly standards conforming, but would break if we added this change: #include static char foo[1024]; int stpcpy(char *str) { if (strlen(str) + strlen(foo) + 1 < sizeof(foo)) { strcat(foo, str); return 1; } else { return 0; } } int main() { printf("stpcpy is %d", stpcpy("foo")); } because string.h on linux defines stpcpy to have a different prototype.... : While non-ANSI standard, this particular function has been : virtually standard in PC compilers for a Long Time. Like I said, near the : start of this, probably for more than a decade it's been in every : DOS/Win/Amiga/OS2/etc compiler I've used (unless my memory fails me, which : it might). So all the DOS compilers have it. Who cares. It isn't standards conforming and encourages people to not know the difference between standard functions and non standard ones. It makes your code harder to read, not easier. DOS isn't the standard, and encourages some very sloppy practices. It makes it harder to port programs written to these oddball, strange, non-standard interfaces. Just because it is in every compiler you have ever used doesn't make it desirable to have it our libc. It has existed in none of the machines that I have used over the past 10 years, although it did exist for the c compiler for my DEC Rainbow 100B. I'm sure a survey of compiler (or rather systems, since unix dices the OS up differently than the Loader known as DOS) would should that the vast majority of them do no, in fact, have this function. : Why is there such vitriol being pointed at people who use a : function that's been in every compiler they've ever had access to, can't : hurt performance, could improve performance of heavily string-oriented : apps, and is small? Quite honestly, I'd assumed that stpcpy() was in : the library already. It is that very fact that is why we're against putting it into our library. : If I want strict ANSI, I'll tell the compiler that. I can't : remember the last time I did that - I think it was when I was beta-testing : commercial compilers 6 or 7 years ago. Part of the problem is that it pollutes the name space. FreeBSD is very careful to not overly pollute things. : As for the bloat argument: Bloat in libraries is very different than bloat : in executables; the impact is MUCH smaller. And as 'bloat' goes, this is : about the most trivial example one could come up with. IMHO. Yes, but if we had 100s of these stupid little things in libc, then it would get too large. It is the camel nose argument: If the nose of a camel comes under the tent, the rest of the camel is sure to follow. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 22:55:13 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 40F7514F9A for ; Sun, 31 Oct 1999 22:55:04 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id HAA04196 for ; Mon, 1 Nov 1999 07:54:58 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id HAA71147 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 07:54:57 +0100 (MET) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 4DC8E14F9A for ; Sun, 31 Oct 1999 22:54:32 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@d60-025.leach.ucdavis.edu [169.237.60.25]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id WAA34224; Sun, 31 Oct 1999 22:54:30 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id WAA24717; Sun, 31 Oct 1999 22:54:30 -0800 (PST) (envelope-from obrien) Date: Sun, 31 Oct 1999 22:54:29 -0800 From: "David O'Brien" To: Dmitrij Tejblum Cc: freebsd-arch@freebsd.org Subject: Re: stpcpy() Message-ID: <19991031225429.A10904@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <19991029151317.E535@holly.calldei.com> <199910302228.CAA03773@tejblum.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <199910302228.CAA03773@tejblum.pp.ru>; from tejblum@arc.hq.cti.ru on Sun, Oct 31, 1999 at 02:28:54AM +0400 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Oct 31, 1999 at 02:28:54AM +0400, Dmitrij Tejblum wrote: > > First it's stpcpy, then GNU getopt, then ... > > Yes. So what? You are suffering from the "NIH" disease. (BTW, stpcpy is > not first and is not GNUism/Linuxism). Then where did it come from? -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 23: 5:56 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id BE413151D6 for ; Sun, 31 Oct 1999 23:05:54 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id IAA04340 for ; Mon, 1 Nov 1999 08:05:53 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA71192 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 08:05:53 +0100 (MET) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id EEC581514F for ; Sun, 31 Oct 1999 23:05:43 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@d60-025.leach.ucdavis.edu [169.237.60.25]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id XAA34261; Sun, 31 Oct 1999 23:05:43 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id XAA27151; Sun, 31 Oct 1999 23:05:42 -0800 (PST) (envelope-from obrien) Date: Sun, 31 Oct 1999 23:05:42 -0800 From: "David O'Brien" To: Randell Jesup Cc: freebsd-arch@freebsd.org Subject: Re: stpcpy() Message-ID: <19991031230542.B10904@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <199910312349.CAA02684@tejblum.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from rjesup@wgate.com on Mon, Nov 01, 1999 at 01:24:10AM +0000 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'll bet 95% of programmers working on systems where stpcpy has been > part of the libraries for a long time don't even know that it isn't > standard. I don't doubt that. Other than BDE and myself, I don't even know of anyone that even has the ANSI-C standard. > I don't know about you, but I code for systems where cutting CPU usage > by 1% can actually make a real difference in the field and to costs. > Perhaps this won't get me 1% - but a fraction of a percent here and > another there adds up, and this is at truely zero cost. So you don't program in C, you use ASM. So you don't program in C++, you use C. Going "down" a step in each of these cases will save you much more than 1%. > While non-ANSI standard, this particular function has been > virtually standard in PC compilers for a Long Time. Like I said, near the > start of this, probably for more than a decade it's been in every > DOS/Win/Amiga/OS2/etc compiler I've used (unless my memory fails me, which > it might). It isn't in Micro$oft C version 6. -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 23:47:48 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 24F2914C96 for ; Sun, 31 Oct 1999 23:47:45 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id IAA04890 for ; Mon, 1 Nov 1999 08:47:44 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA71339 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 08:47:43 +0100 (MET) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (Postfix) with ESMTP id 5C41014C96 for ; Sun, 31 Oct 1999 23:47:34 -0800 (PST) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.3/8.9.1) id SAA63912; Mon, 1 Nov 1999 18:57:05 +1100 (EST) (envelope-from jb) Date: Mon, 1 Nov 1999 18:57:05 +1100 From: John Birrell To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads goals version III Message-ID: <19991101185705.A55580@freebsd1.cimlogic.com.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: ; from Julian Elischer on Sun, Oct 31, 1999 at 07:09:04PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ Grrr, I'm obviously in a different timezone from this discussion. ] On Sun, Oct 31, 1999 at 07:09:04PM -0800, Julian Elischer wrote: > 10/ Quick access to curthread and thread specific data. 10a/ Quick access to mutex state. One of the things that affects the performance of a threaded application is the time that is consumed testing the state of a mutex. Without trying to push this discussion into the "how it should be done phase", just consider sharing mutex state between user- and kernel- space. We will need a VM wizard at some point. 8-) > ---- possible userland implementation goals----- > > 1/ A libpthread that can be linked with libc. > > 2/ Libc needs to change so that library functions and system calls > used internal to the library do not use the externally visible > cancellable equivalents. A big re-write of libc is required. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ john.birrell@cai.com john.birrell@opendirectory.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 31 23:56:27 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 63D4414C96 for ; Sun, 31 Oct 1999 23:56:24 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id IAA05011 for ; Mon, 1 Nov 1999 08:56:23 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA71375 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 08:56:23 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 1A84B14C96 for ; Sun, 31 Oct 1999 23:56:16 -0800 (PST) (envelope-from julian@whistle.com) Received: from home.elischer.org (home.elischer.org [207.76.204.203]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id XAA35748; Sun, 31 Oct 1999 23:56:08 -0800 (PST) Date: Sun, 31 Oct 1999 23:56:05 -0800 (PST) From: Julian Elischer X-Sender: julian@home.elischer.org To: John Birrell Cc: freebsd-arch@freebsd.org Subject: Re: Threads goals version III In-Reply-To: <19991101185705.A55580@freebsd1.cimlogic.com.au> 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 It's been remarkably placid, you haven't missed a thing.. On Mon, 1 Nov 1999, John Birrell wrote: > [ Grrr, I'm obviously in a different timezone from this discussion. ] > > On Sun, Oct 31, 1999 at 07:09:04PM -0800, Julian Elischer wrote: > > 10/ Quick access to curthread and thread specific data. > > 10a/ Quick access to mutex state. > > One of the things that affects the performance of a threaded application > is the time that is consumed testing the state of a mutex. Without trying > to push this discussion into the "how it should be done phase", just > consider sharing mutex state between user- and kernel- space. We will > need a VM wizard at some point. 8-) > > > ---- possible userland implementation goals----- > > > > 1/ A libpthread that can be linked with libc. > > > > 2/ Libc needs to change so that library functions and system calls > > used internal to the library do not use the externally visible > > cancellable equivalents. > > A big re-write of libc is required. > > -- > John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ > john.birrell@cai.com john.birrell@opendirectory.com.au > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 0:52:51 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id BF52314C1C for ; Mon, 1 Nov 1999 00:52:40 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id JAA05968 for ; Mon, 1 Nov 1999 09:52:39 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA71483 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 09:52:38 +0100 (MET) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (Postfix) with ESMTP id 5833B14C1C for ; Mon, 1 Nov 1999 00:52:00 -0800 (PST) (envelope-from michael.schuster@germany.sun.com) Received: from emuc05-home.Germany.Sun.COM ([129.157.51.10]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA18078 for ; Mon, 1 Nov 1999 00:51:58 -0800 (PST) Received: from germany.sun.com (hacker [129.157.167.97]) by emuc05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with ESMTP id JAA04170 for ; Mon, 1 Nov 1999 09:51:57 +0100 (MET) Message-ID: <381D54AF.8C292233@germany.sun.com> Date: Mon, 01 Nov 1999 09:51:59 +0100 From: Michael Schuster - TSC SunOS Germany Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: Threads goals version III References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > 2/ Ability to simultaneously schedule M threads over N Processors, > and have min(M,N) threads simultaneously executing. > 2A/ ability to tune and control the above.. > > 3/ just because one thread blocks, doesn't mean that > the others can't keep running. > IMO, 3/ should be 2B/, since it's just another facet of the same thing. I'll try to give my view of the relationship of these things (has been voiced differently already, I'm just collecting): what we need: - entities that are treated as distinct by the kernel with respect to execution and scheduling (kernel threads). This is a direct requirement for simultaneous execution on seperate CPUs. - entities within a user process that can be scheduled independently from one another from the application's POV (userland threads - big surprise :-). Apart from the evidence of pthreads and other implementations, this is a requirement for clean code in many applications. - a mechanism for mapping _one_or_more_ userland threads (within the same process) to a kernel thread. Solaris (yes, I'm biased :-) uses the term lightweight process here (so, to contradict Dan, if I remember correctly, this is not the same thing). why not a 1:1 mapping of kernel threads to user threads? basically, cost (kernel memory & execution time) (guess why NT can't support hotmail ...:-) This is discussed in many papers... Scheduler activations as described in the Anderson et al. paper seem a good tool to circumvent some of the hurdles presenting themselves. In general, I think we should also define our meta-goals here (without any prioritisation yet): *) scalability *) performance *) any others? regards Michael -- Michael Schuster / Michael.Schuster@germany.sun.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 2:25:16 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 8ACCA14E04 for ; Mon, 1 Nov 1999 02:25:13 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id LAA09283 for ; Mon, 1 Nov 1999 11:25:12 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA71748 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 11:25:12 +0100 (MET) Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id 520E014E04 for ; Mon, 1 Nov 1999 02:24:55 -0800 (PST) (envelope-from freebsd-arch@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id KAA81649 for arch@FreeBSD.org; Mon, 1 Nov 1999 10:56:49 +0100 (CET) (envelope-from freebsd-arch@scc.nl) Received: from GATEWAY by dwarf.hq.scc.nl with netnews for arch@FreeBSD.org (arch@FreeBSD.org) To: arch@freebsd.org Date: Mon, 01 Nov 1999 10:56:42 +0100 From: Marcel Moolenaar Message-ID: <381D63DA.EE8DD41F@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <199911010347.WAA20149@pcnet1.pcnet.com>, <199911010412.VAA14975@mt.sri.com> Subject: Re: Threads models and FreeBSD / Threads goals version II Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams wrote: > > No, I want to be able to have multiple threads in a single process > > be in kernel space. Only one can be running, but others can be > > blocked. > > Agreed. My point is that if we allow multiple threads in a single > process in the kernel space, it's alot worse than the present tsleep > issues.... From rev 2: 2/ Ability to simultaneously schedule M threads over N Processors. I interpret this as "allow multiple threads from a single process to run concurrently on different processors". Without restriction, this implies that they may run in kernel space simultaneously. It should be perfectly clear what we mean, because I fear inconsistencies. -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 3:12:18 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 477B014F45 for ; Mon, 1 Nov 1999 03:12:15 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id MAA10671 for ; Mon, 1 Nov 1999 12:12:13 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id MAA72029 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 12:12:13 +0100 (MET) Received: from m4.c2.telstra-mm.net.au (m4.c2.telstra-mm.net.au [24.192.3.19]) by hub.freebsd.org (Postfix) with ESMTP id A2F0514F45 for ; Mon, 1 Nov 1999 03:11:57 -0800 (PST) (envelope-from areilly@nsw.bigpond.net.au) Received: from m5.c2.telstra-mm.net.au (m5.c2.telstra-mm.net.au [24.192.3.20]) by m4.c2.telstra-mm.net.au (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id WAA27478 for ; Mon, 1 Nov 1999 22:11:56 +1100 (EDT) X-BPC-Relay-Envelope-From: areilly@nsw.bigpond.net.au X-BPC-Relay-Envelope-To: X-BPC-Relay-Sender-Host: m5.c2.telstra-mm.net.au [24.192.3.20] X-BPC-Relay-Info: Message delivered directly. Received: from areilly.bpc-users.org (CPE-24-192-49-170.nsw.bigpond.net.au [24.192.49.170]) by m5.c2.telstra-mm.net.au (8.8.6 (PHNE_14041)/8.8.6) with SMTP id WAA20616 for ; Mon, 1 Nov 1999 22:11:54 +1100 (EDT) Received: (qmail 75126 invoked by uid 1000); 1 Nov 1999 11:11:55 -0000 From: "Andrew Reilly" Date: Mon, 1 Nov 1999 22:11:55 +1100 To: Michael Schuster - TSC SunOS Germany Cc: freebsd-arch@freebsd.org Subject: Re: Threads goals version III Message-ID: <19991101221155.A74292@gurney.reilly.home> References: <381D54AF.8C292233@germany.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <381D54AF.8C292233@germany.sun.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Nov 01, 1999 at 09:51:59AM +0100, Michael Schuster - TSC SunOS Germany wrote: > *) scalability > *) performance > > *) any others? *) supports the thread requirements of all of the API compatability modules? -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 4:28:51 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 21C48150B3 for ; Mon, 1 Nov 1999 04:28:45 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA12338 for ; Mon, 1 Nov 1999 13:28:37 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA72259 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 13:28:27 +0100 (MET) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id DB2F0150B3 for ; Mon, 1 Nov 1999 04:27:59 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p26-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.155]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id VAA29829; Mon, 1 Nov 1999 21:27:48 +0900 (JST) Message-ID: <381D7E0C.BDA0204C@newsguy.com> Date: Mon, 01 Nov 1999 20:48:28 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Nate Williams Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads goals version II References: <199911010225.TAA14010@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams wrote: > > > 3/ One blocking thread cannot block another thread. > > Blocking of one thread does not imply that other threads be > > blocked. > > How about instead of 'cannot' we use the word 'does not necessarily' > block another thread, and then append 'unless it does using programatic > means'. Suggestion: the blocking of a thread does not have the side effect of blocking other threads. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "People call him Neutron Star, 'cuz he's so dense lights bends around him." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 4:29: 0 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 45EEA15105 for ; Mon, 1 Nov 1999 04:28:38 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA12333 for ; Mon, 1 Nov 1999 13:28:32 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA72243 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 13:28:16 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id EF2BB150A8 for ; Mon, 1 Nov 1999 04:27:54 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id HAA11398; Mon, 1 Nov 1999 07:26:39 -0500 (EST) Date: Mon, 1 Nov 1999 07:26:39 -0500 (EST) From: Daniel Eischen Message-Id: <199911011226.HAA11398@pcnet1.pcnet.com> To: freebsd-arch@freebsd.org, michael.schuster@germany.sun.com Subject: Re: Threads goals version III Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > - a mechanism for mapping _one_or_more_ userland threads (within the > same process) to a kernel thread. Solaris (yes, I'm biased :-) uses the > term lightweight process here (so, to contradict Dan, if I remember > correctly, this is not the same thing). Actually, I'm the one who said a Solaris [pthread] thread is not equivalent to a lightweight process. In Solaris, there are: o Application [user] threads which run over one or more lightweight processes. o Lightweight processes which run on kernel threads o Kernel threads as the basic scheduling entity - these do not have to be mapped to an LWP Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 4:29: 3 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 4DAB715215 for ; Mon, 1 Nov 1999 04:28:54 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA12342 for ; Mon, 1 Nov 1999 13:28:46 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA72277 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 13:28:37 +0100 (MET) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 0C0AB15105 for ; Mon, 1 Nov 1999 04:28:06 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p26-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.155]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id VAA29867; Mon, 1 Nov 1999 21:27:56 +0900 (JST) Message-ID: <381D8046.812922F6@newsguy.com> Date: Mon, 01 Nov 1999 20:57:58 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Daniel Eischen Cc: julian@whistle.com, nate@mt.sri.com, freebsd-arch@freebsd.org Subject: Re: Threads goals version II References: <199911010341.WAA19654@pcnet1.pcnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel Eischen wrote: > > Well, that wasn't the intent. My use of lightweight process was to > mean a process. I believe that threads and lightweight processes > mean different things in Solaris. Reword it any way you see fit. Not sure how are things these days there, but maybe they refer to lwp as their previous implementation (userland threads) and threads as their present implementation (kernel threads)? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "People call him Neutron Star, 'cuz he's so dense lights bends around him." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 4:29:20 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 9D4F2150B3 for ; Mon, 1 Nov 1999 04:29:15 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA12360 for ; Mon, 1 Nov 1999 13:29:14 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA72304 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 13:29:14 +0100 (MET) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 3ADEF15241 for ; Mon, 1 Nov 1999 04:28:12 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p26-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.155]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id VAA29915; Mon, 1 Nov 1999 21:28:06 +0900 (JST) Message-ID: <381D8544.420B131B@newsguy.com> Date: Mon, 01 Nov 1999 21:19:16 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Nate Williams Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads goals version II References: <199911010225.TAA14010@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams wrote: > > > 10/ Quick access to curthread and thread specific data. We shouldn't > > have to enter the kernel to get this. This should also be true > > for threads spread across multiple [lightweight] processes. > > The last sentence is redundant, since threads are by definition > lightweight processes. :) Lightweight processes are threads by one definition. I have been assuming the person who originally mentioned this (Daniel Eischen) had another definition of lwp in mind. I'll now stop assuming and call for clear definition of what a lightweight process is, or, failing that, removal of the above. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "People call him Neutron Star, 'cuz he's so dense lights bends around him." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 4:29:24 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 20B4115163 for ; Mon, 1 Nov 1999 04:29:14 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA12354 for ; Mon, 1 Nov 1999 13:29:12 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA72291 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 13:29:12 +0100 (MET) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 9174F15249 for ; Mon, 1 Nov 1999 04:28:12 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p26-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.155]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id VAA29926; Mon, 1 Nov 1999 21:28:09 +0900 (JST) Message-ID: <381D86B6.3D20E0E7@newsguy.com> Date: Mon, 01 Nov 1999 21:25:26 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Daniel Eischen Cc: freebsd-arch@freebsd.org Subject: Re: Threads goals version II References: <199911010443.XAA26092@pcnet1.pcnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [slightly off-topic] Daniel Eischen wrote: > > What happens under LinuxThreads? I'd expect an rfork'd process to > get an equal share of processor time as it's parent. If I create > 10 threads with PTHREAD_SCOPE_SYSTEM, I expect to have 10 LWPs (or > rfork'd processes). What I am trying to say is that an application > that creates 10 threads with PTHREAD_SCOPE_SYSTEM gets more processor > time than 8 threads with PTHREAD_SCOPE_SYSTEM and 2 threads with > PTHREAD_SCOPE_PROCESS. Some people (most people on the FreeBSD campus who have been involved with threads, it would seem) think that having more threads for the purpose of increasing your time slice is bad behavior, to say the least. Unix have a mechanism to adjust the relative priority between processes, which is called priority. If a process is supposed to eat more cpu time than others, it is given a lower priority than the others. Having a programmer get around the admin mechanism to adjust process priority through use of threads might led to a situation where competing users end up bogging down the whole system while fighting for cpu time. I can see clear disadvantages in allowing a process cpu time be allotted according to how many threads it has. Do you see any particular disadvantage to nice(1)? MMmmm... I should removed this last sentence before sending this message, it comes too aggressive, but I can't think of any better way of getting the point across. Anyway, this is the "contention" point that has been mentioned. Many people here _want_ all processes to be equal, no matter how many threads they run. Instead of trying to convince people to see the light, just ask that your dissent be noted, or that both capabilities be present. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "People call him Neutron Star, 'cuz he's so dense lights bends around him." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 4:35:38 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D17DA150A8 for ; Mon, 1 Nov 1999 04:35:34 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA12530 for ; Mon, 1 Nov 1999 13:35:32 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA72369 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 13:35:32 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id B11BB150A8 for ; Mon, 1 Nov 1999 04:35:17 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id HAA12131; Mon, 1 Nov 1999 07:34:01 -0500 (EST) Date: Mon, 1 Nov 1999 07:34:01 -0500 (EST) From: Daniel Eischen Message-Id: <199911011234.HAA12131@pcnet1.pcnet.com> To: jb@cimlogic.com.au, julian@whistle.com Subject: Re: Threads goals version III Cc: freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 10a/ Quick access to mutex state. > > One of the things that affects the performance of a threaded application > is the time that is consumed testing the state of a mutex. Without trying > to push this discussion into the "how it should be done phase", just > consider sharing mutex state between user- and kernel- space. We will > need a VM wizard at some point. 8-) I think scheduler activations solves this problem, so that the kernel need not now if a thread holds critical resources such as a mutex. Under scheduler activations, the threads library is informed of all events that affect scheduling, so that if a thread is swapped out while holding a critical resource, it can be resumed on the next available LWP. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 4:39:44 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id E66FF150A8 for ; Mon, 1 Nov 1999 04:39:40 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA12627 for ; Mon, 1 Nov 1999 13:39:34 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA72399 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 13:39:33 +0100 (MET) Received: from hda.hda.com (hda.bicnet.net [208.220.68.243]) by hub.freebsd.org (Postfix) with ESMTP id B59D7150A8 for ; Mon, 1 Nov 1999 04:39:24 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id HAA17742; Mon, 1 Nov 1999 07:33:53 -0500 (EST) From: Peter Dufault Message-Id: <199911011233.HAA17742@hda.hda.com> Subject: Re: Threads goals version III In-Reply-To: from Julian Elischer at "Oct 31, 99 07:09:04 pm" To: julian@whistle.com (Julian Elischer) Date: Mon, 1 Nov 1999 07:33:52 -0500 (EST) Cc: freebsd-arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 4/ All threads in a processs see the same address space (exactly). Stacks too? Is that a rule implied from POSIX or one for portability? Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 4:48: 5 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id BECB2150A8 for ; Mon, 1 Nov 1999 04:48:01 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA12819 for ; Mon, 1 Nov 1999 13:47:56 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA72428 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 13:47:53 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 21A3A150A8 for ; Mon, 1 Nov 1999 04:47:39 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id HAA13624; Mon, 1 Nov 1999 07:46:22 -0500 (EST) Date: Mon, 1 Nov 1999 07:46:22 -0500 (EST) From: Daniel Eischen Message-Id: <199911011246.HAA13624@pcnet1.pcnet.com> To: dcs@newsguy.com, eischen@vigrid.com Subject: Re: Threads goals version II Cc: freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Some people (most people on the FreeBSD campus who have been > involved with threads, it would seem) think that having more threads > for the purpose of increasing your time slice is bad behavior, to > say the least. Unix have a mechanism to adjust the relative priority > between processes, which is called priority. If a process is > supposed to eat more cpu time than others, it is given a lower > priority than the others. An application can fork just as well as create threads. You're not stopping anything here. > Having a programmer get around the admin mechanism to adjust process > priority through use of threads might led to a situation where > competing users end up bogging down the whole system while fighting > for cpu time. Again, what's the difference between fork and creating a thread with a new LWP? Count LWPs along with processes and keep it within the limits of maxproc. > Anyway, this is the "contention" point that has been mentioned. Many > people here _want_ all processes to be equal, no matter how many > threads they run. Instead of trying to convince people to see the > light, just ask that your dissent be noted, or that both > capabilities be present. Consider this notification. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 6:14:13 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 93E6014FF9 for ; Mon, 1 Nov 1999 06:13:58 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id PAA01743 for ; Mon, 1 Nov 1999 15:13:56 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA72693 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 15:13:56 +0100 (MET) Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 11E0C14FF9 for ; Mon, 1 Nov 1999 06:13:46 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id JAA19526 for ; Mon, 1 Nov 1999 09:09:04 -0500 (EST) Reply-To: Randell Jesup To: freebsd-arch@freebsd.org Subject: Re: stpcpy() References: <199910312349.CAA02684@tejblum.pp.ru> <19991031230542.B10904@dragon.nuxi.com> From: Randell Jesup Date: 01 Nov 1999 10:10:15 +0000 In-Reply-To: "David O'Brien"'s message of "Sun, 31 Oct 1999 23:05:42 -0800" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "David O'Brien" writes: >> I don't know about you, but I code for systems where cutting CPU usage >> by 1% can actually make a real difference in the field and to costs. >> Perhaps this won't get me 1% - but a fraction of a percent here and >> another there adds up, and this is at truely zero cost. > >So you don't program in C, you use ASM. So you don't program in C++, >you use C. Going "down" a step in each of these cases will save you much >more than 1%. At an order of magnitude increase in cost and maintainance cost, and loss of portability. Don't think I'm shy to use ASM; I've worked on entire multi-threaded FS's in ASM - but it should be used exceeedingly sparingly (of course) in what's inherently multi-platform code. >> While non-ANSI standard, this particular function has been >> virtually standard in PC compilers for a Long Time. Like I said, near the >It isn't in Micro$oft C version 6. If true (for the current version?), that's a reasonable argument. (As are some of Warner's arguments.) Where did it come from? SysV?? I know Lattice had it back in the mid/late 80's. If it's not included, it adds to the case for a compat (libinuxcompat?) library. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 7:16:25 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2F66F14FD8 for ; Mon, 1 Nov 1999 07:16:18 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id QAA03226 for ; Mon, 1 Nov 1999 16:16:16 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA73057 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 16:16:16 +0100 (MET) Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id CF25114FD8 for ; Mon, 1 Nov 1999 07:15:58 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id KAA22175 for ; Mon, 1 Nov 1999 10:11:15 -0500 (EST) Reply-To: Randell Jesup To: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. References: <199910312340.QAA12893@mt.sri.com> <199911010116.SAA13482@mt.sri.com> From: Randell Jesup Date: 01 Nov 1999 11:12:25 +0000 In-Reply-To: Nate Williams's message of "Sun, 31 Oct 1999 18:16:19 -0700" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams writes: >Another thing I'd like to add to the requirements list is that the >threads use 'standard' threading mechanisms for safety, such as >mutex/semaphore, etc.., which should exist in the kernel as well. Yes, absolutely. >This is inline with the Posix stuff, and rather than invent our 'own' >new kind of data structure, I'd like to stick with known solutions that >work and everyone for the most part understands. Ditto. Here's one idea : I've worked on natively threaded (from the start) OS's in the past which allowed there to be thread-specific data that could be accessed with a (system) call (or structure reference) from the user level. One object-oriented OS allowed arbitrary attributes to be added to thread objects dynamically (which can be emulated in any OS that allows a single thread-specific pointer that can be fetched/set). This allowed for user-level data similar to the thread-specific data in the kernel (such as currentdir, which the (usermode) filesystem object module added to a thread when it was set). This may be significantly heavier than we'd wish, and there may be other reasons in a general-purpose open OS to not allow this (such as worrying about different accessors trying to use a single thread-specific datum - though an extensible (named or ID'd) attribute scheme solves that). I think it's moderately common in embedded OS's (which can be threads-only, with no heavyweight processes). -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 7:29:36 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 1BBFE14FD8 for ; Mon, 1 Nov 1999 07:29:29 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id QAA03453 for ; Mon, 1 Nov 1999 16:29:28 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA73182 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 16:29:28 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 99A1114FD8 for ; Mon, 1 Nov 1999 07:29:15 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id IAA14662; Mon, 1 Nov 1999 08:29:14 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id IAA17050; Mon, 1 Nov 1999 08:29:13 -0700 Date: Mon, 1 Nov 1999 08:29:13 -0700 Message-Id: <199911011529.IAA17050@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Daniel Eischen Cc: nate@mt.sri.com, freebsd-arch@freebsd.org, julian@whistle.com Subject: Re: Threads models and FreeBSD. In-Reply-To: <199911010453.XAA27221@pcnet1.pcnet.com> References: <199911010453.XAA27221@pcnet1.pcnet.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > No, I want to be able to have multiple threads in a single process > > > be in kernel space. Only one can be running, but others can be > > > blocked. > > > > Agreed. My point is that if we allow multiple threads in a single > > process in the kernel space, it's alot worse than the present tsleep > > issues.... > > Perhaps I haven't thought this through enough, but why? See my other email on this topic, regarding deadlock and such... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 7:34:46 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id EBACD14FD8 for ; Mon, 1 Nov 1999 07:34:43 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id QAA03565 for ; Mon, 1 Nov 1999 16:34:42 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA73218 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 16:34:42 +0100 (MET) Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 421F3151C8 for ; Mon, 1 Nov 1999 07:34:32 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id KAA23101 for ; Mon, 1 Nov 1999 10:29:48 -0500 (EST) Reply-To: Randell Jesup To: freebsd-arch@freebsd.org Subject: Re: Storing small files in inodes References: <99Oct29.085056est.40332@border.alcanet.com.au> <19991029150228.BB45314BF7@hub.freebsd.org> <99Nov1.100916est.40382@border.alcanet.com.au> From: Randell Jesup Date: 01 Nov 1999 11:30:58 +0000 In-Reply-To: Peter Jeremy's message of "Mon, 1 Nov 1999 10:13:35 +1100" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Jeremy writes: >>http://www.usenix.org/publications/library/proceedings/ana97/ganger.html >> >>With embedded inodes, the inodes for most files are stored in the >>directory with the corresponding name, removing a physical level of >>indirection without sacrificing the logical level of indirection. With >>explicit grouping, the data blocks of multiple small files named by a >>given directory are allocated adjacently and moved to and from the >>disk as a unit in most cases. > >C-FFS is a more radical change than I was thinking of. By moving the >inodes into the directory, it needs special handling for files don't >have exactly 1 link. True, though this is similar (in complexity) to the special handling for small files inside inodes - probably simpler, given issues of mmap/etc for the later. >Also, from my reading of the paper, a small >file still occupies a complete data block, it's just that the data >block is `close to' the directory entry/inode for the file. True. However, saving the extra level of indirection and the improved match to the physical characteristics of modern drives is a major win. The tendency is that the small file block will be in the cache anyways, or at worst within the drive's cache. You could preferentially put smaller files closer to the directory nodes. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 10: 6:22 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C53BE15035 for ; Mon, 1 Nov 1999 10:06:18 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA05680 for ; Mon, 1 Nov 1999 19:06:17 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA74142 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 19:06:16 +0100 (MET) Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by hub.freebsd.org (Postfix) with ESMTP id 7E95C15009 for ; Mon, 1 Nov 1999 10:06:04 -0800 (PST) (envelope-from gibbs@caspian.plutotech.com) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id KAA00397; Mon, 1 Nov 1999 10:06:09 -0700 (MST) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <199911011706.KAA00397@caspian.plutotech.com> X-Mailer: exmh version 2.1.0 09/18/1999 To: nate@mt.sri.com (Nate Williams) Cc: Julian Elischer , Daniel Eischen , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-reply-to: Your message of "Sun, 31 Oct 1999 19:19:25 MST." <199911010219.TAA13936@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Nov 1999 10:06:09 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> > 11.) Ability for the threads library to cancel/terminate a thread >> > blocked in the kernel. >> >> oooooh > >Oooh is right. This has the potential to deadlock the kernel if the >thread owns some sort of 'thread' resources. Justin and I were having a >discussion about this very thing earlier today, and I don't think I was >able to express myself well, so here it goes again. > >Basically, what happens if a particular thread owns a resource that >others are blocking on, and it's woken up 'prematurely'? If the thread >is aborted out of the kernel, the other threads (which might exist in >the kernel) may not be woken up (ever), thus causing zombie threads. > >If you take this further, it's possible that you can introduce deadlock >and/or races very easily when you allow threads to be aborted. >Unfortunately, I'm all too familiar with this problem, having been able >to design a system that all too often exhibits this behavior. :) The solution to these kinds of problems is to provide an exception mechanism for threads that are in the kernel. When you wish to abort a thread, the thread is forced into an exception state and unwinds its stack and the releases its resources in a programmatic fashion. I'm not advocating rewriting the kernel in C++, but adding a C exception mechanism with try/catch type semantics is a very clean way of dealing with these kinds of issues. With PC range tables, you can get this feature with 0 runtime penalty other than having your exception code in core but far removed from your execute path. There are several situations where you really do want to abort threads in a kernel context (even those that are not explicitly sleeping) and whatever solution we devise should allow for it to occur. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 11:13:23 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6BEC014F2C for ; Mon, 1 Nov 1999 11:13:18 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA06452 for ; Mon, 1 Nov 1999 20:13:17 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA74514 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 20:13:16 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 9C6E315031; Mon, 1 Nov 1999 11:07:51 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id MAA16808; Mon, 1 Nov 1999 12:07:43 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id MAA18241; Mon, 1 Nov 1999 12:07:42 -0700 Date: Mon, 1 Nov 1999 12:07:42 -0700 Message-Id: <199911011907.MAA18241@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: nate@mt.sri.com (Nate Williams), Julian Elischer , Daniel Eischen , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: <199911011706.KAA00397@caspian.plutotech.com> References: <199911010219.TAA13936@mt.sri.com> <199911011706.KAA00397@caspian.plutotech.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> > 11.) Ability for the threads library to cancel/terminate a thread > >> > blocked in the kernel. > >> > >> oooooh > > > >Oooh is right. This has the potential to deadlock the kernel if the > >thread owns some sort of 'thread' resources. Justin and I were having a > >discussion about this very thing earlier today, and I don't think I was > >able to express myself well, so here it goes again. > > > >Basically, what happens if a particular thread owns a resource that > >others are blocking on, and it's woken up 'prematurely'? If the thread > >is aborted out of the kernel, the other threads (which might exist in > >the kernel) may not be woken up (ever), thus causing zombie threads. > > > >If you take this further, it's possible that you can introduce deadlock > >and/or races very easily when you allow threads to be aborted. > >Unfortunately, I'm all too familiar with this problem, having been able > >to design a system that all too often exhibits this behavior. :) > > The solution to these kinds of problems is to provide an exception > mechanism for threads that are in the kernel. When you wish to abort > a thread, the thread is forced into an exception state and unwinds its > stack and the releases its resources in a programmatic fashion. I'm > not advocating rewriting the kernel in C++, but adding a C exception > mechanism with try/catch type semantics is a very clean way of dealing > with these kinds of issues. You and I are on the same track here. This is the kind of functionality I would like to see, and I proposed something like that in an email to the group. The only downsides to execption handling is that it often makes your code a bit harder to read if you get really anal about exception handling. :) > There are several situations where you really do want to abort threads > in a kernel context (even those that are not explicitly sleeping) and > whatever solution we devise should allow for it to occur. Agreed, but it needs to be a 'signal' or an 'exception' to the thread, so the thread itself can unwind, rather than having it abort. That way the thread itself can clean up as it sees fit... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 11:37:35 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D13DC14C19 for ; Mon, 1 Nov 1999 11:37:31 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA06724 for ; Mon, 1 Nov 1999 20:37:29 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA74681 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 20:37:29 +0100 (MET) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 9F55914C19; Mon, 1 Nov 1999 11:36:25 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id MAA02540; Mon, 1 Nov 1999 12:36:23 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd002498; Mon Nov 1 12:36:13 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id MAA29291; Mon, 1 Nov 1999 12:36:13 -0700 (MST) From: Terry Lambert Message-Id: <199911011936.MAA29291@usr02.primenet.com> Subject: Re: stpcpy() To: obrien@freebsd.org Date: Mon, 1 Nov 1999 19:36:13 +0000 (GMT) Cc: rjesup@wgate.com, freebsd-arch@freebsd.org In-Reply-To: <19991029234654.B89583@dragon.nuxi.com> from "David O'Brien" at Oct 29, 99 11:46:55 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Fri, Oct 29, 1999 at 03:58:14PM +0000, Randell Jesup wrote: > > stpcpy() (the issue in this case) is something I've seen in > > compiler's C libraries since the late 80's/early 90's (if I remember > > correctly), if I remember correctly. Quite honestly, it's useful > ... > > It's handy and improves performance for the cases where it's > > Why is it so useful and "improves" performance so much?? I'll only > believe this when I see some perf traces. Strings don't tend to be very > long ( < 256). Thus an c*O(n), where c = (2 + 1 function call) doesn't > sound like a big savings. Especially in the face of portability. > > I really think 99% of the programs using stpcpy() for "speed" reasons > would spend 99% of their time elsewhere if p=strchr(strcpy(d,s), '\0'); > were used. I believe the point is to iterate the string once, instead of twice, without having to learn how to use pointers yourself. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 11:47:30 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id EFF3C14FF6 for ; Mon, 1 Nov 1999 11:47:27 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA06842 for ; Mon, 1 Nov 1999 20:47:25 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA74748 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 20:47:25 +0100 (MET) Received: from hda.hda.com (hda.bicnet.net [208.220.68.243]) by hub.freebsd.org (Postfix) with ESMTP id E6CDD14E8F for ; Mon, 1 Nov 1999 11:41:54 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id OAA18744; Mon, 1 Nov 1999 14:36:22 -0500 (EST) From: Peter Dufault Message-Id: <199911011936.OAA18744@hda.hda.com> Subject: Re: Threads models and FreeBSD. In-Reply-To: <199911010221.TAA13961@mt.sri.com> from Nate Williams at "Oct 31, 99 07:21:20 pm" To: nate@mt.sri.com Date: Mon, 1 Nov 1999 14:36:22 -0500 (EST) Cc: julian@whistle.com, nate@mt.sri.com, freebsd-arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > but that's wrong.. the memory is shared.. > > only the %sp register is differnet.. > > Right, my bad. > > Here's what I wrote to Sean. > > Thread share everything that a normal process, including a > thread-specific stack which is used to keep each thread's context > seperate from one another. I haven't caught up with you guys yet. This is what I asked about POSIX threading before: can stack be private per thread? There are obvious cacheing advantages, especially with threads across multiple processors. I'll have to buy the spec. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 11:59:45 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6D65A14FF7 for ; Mon, 1 Nov 1999 11:59:29 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA07036 for ; Mon, 1 Nov 1999 20:59:27 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA74862 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 20:59:25 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id AE1AA152F2; Mon, 1 Nov 1999 11:56:37 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id OAA15599; Mon, 1 Nov 1999 14:55:19 -0500 (EST) Date: Mon, 1 Nov 1999 14:55:18 -0500 (EST) From: Daniel Eischen To: Nate Williams Cc: "Justin T. Gibbs" , Nate Williams , Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: <199911011907.MAA18241@mt.sri.com> 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, 1 Nov 1999, Nate Williams wrote: > You and I are on the same track here. This is the kind of functionality > I would like to see, and I proposed something like that in an email to > the group. The only downsides to execption handling is that it often > makes your code a bit harder to read if you get really anal about > exception handling. :) > > > There are several situations where you really do want to abort threads > > in a kernel context (even those that are not explicitly sleeping) and > > whatever solution we devise should allow for it to occur. > > Agreed, but it needs to be a 'signal' or an 'exception' to the thread, > so the thread itself can unwind, rather than having it abort. > > That way the thread itself can clean up as it sees fit... What about being able to push and pop cleanup handlers in the kernel? It's not quite as elegant as exception handlers, but would it accomplish what you want? Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 12: 3: 0 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 53F3A14A2F for ; Mon, 1 Nov 1999 12:02:46 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA07079 for ; Mon, 1 Nov 1999 21:02:41 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA74891 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 21:02:41 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 6663E14BE5; Mon, 1 Nov 1999 12:02:10 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id NAA17348; Mon, 1 Nov 1999 13:02:07 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA18597; Mon, 1 Nov 1999 13:02:02 -0700 Date: Mon, 1 Nov 1999 13:02:02 -0700 Message-Id: <199911012002.NAA18597@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Daniel Eischen Cc: Nate Williams , "Justin T. Gibbs" , Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: References: <199911011907.MAA18241@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > You and I are on the same track here. This is the kind of functionality > > I would like to see, and I proposed something like that in an email to > > the group. The only downsides to execption handling is that it often > > makes your code a bit harder to read if you get really anal about > > exception handling. :) > > > > > There are several situations where you really do want to abort threads > > > in a kernel context (even those that are not explicitly sleeping) and > > > whatever solution we devise should allow for it to occur. > > > > Agreed, but it needs to be a 'signal' or an 'exception' to the thread, > > so the thread itself can unwind, rather than having it abort. > > > > That way the thread itself can clean up as it sees fit... > > What about being able to push and pop cleanup handlers in the > kernel? It's not quite as elegant as exception handlers, but > would it accomplish what you want? I think the complexity would be much greater, but maybe I don't understand fully what you are saying. Can you give a simple code example? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 12: 3:11 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 87636152E4 for ; Mon, 1 Nov 1999 12:03:04 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA07093 for ; Mon, 1 Nov 1999 21:03:02 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA74905 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 21:03:02 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id E7B8C14A2F for ; Mon, 1 Nov 1999 12:02:39 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id NAA17352; Mon, 1 Nov 1999 13:02:35 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA18614; Mon, 1 Nov 1999 13:02:34 -0700 Date: Mon, 1 Nov 1999 13:02:34 -0700 Message-Id: <199911012002.NAA18614@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Peter Dufault Cc: nate@mt.sri.com, julian@whistle.com, freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: <199911011936.OAA18744@hda.hda.com> References: <199911010221.TAA13961@mt.sri.com> <199911011936.OAA18744@hda.hda.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > but that's wrong.. the memory is shared.. > > > only the %sp register is differnet.. > > > > Right, my bad. > > > > Here's what I wrote to Sean. > > > > Thread share everything that a normal process, including a > > thread-specific stack which is used to keep each thread's context > > seperate from one another. > > I haven't caught up with you guys yet. This is what > I asked about POSIX threading before: can stack be private per > thread? I don't believe so, although each thread does have it's own stack, it's not private. Sean would know more though.... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 12: 5:14 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6542214A2F for ; Mon, 1 Nov 1999 12:05:07 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA07147 for ; Mon, 1 Nov 1999 21:05:05 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA74943 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 21:05:05 +0100 (MET) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id CB06C1503C; Mon, 1 Nov 1999 12:04:23 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id NAA17795; Mon, 1 Nov 1999 13:03:49 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpdAAAVia4MI; Mon Nov 1 13:03:45 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id NAA00280; Mon, 1 Nov 1999 13:04:05 -0700 (MST) From: Terry Lambert Message-Id: <199911012004.NAA00280@usr02.primenet.com> Subject: Re: stpcpy() To: obrien@freebsd.org Date: Mon, 1 Nov 1999 20:04:04 +0000 (GMT) Cc: tejblum@arc.hq.cti.ru, freebsd-arch@freebsd.org In-Reply-To: <19991031225429.A10904@dragon.nuxi.com> from "David O'Brien" at Oct 31, 99 10:54:29 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Sun, Oct 31, 1999 at 02:28:54AM +0400, Dmitrij Tejblum wrote: > > > First it's stpcpy, then GNU getopt, then ... > > > > Yes. So what? You are suffering from the "NIH" disease. (BTW, stpcpy is > > not first and is not GNUism/Linuxism). > > Then where did it come from? Borland Turbo-C, and thereafter it was quickly adopted by Microsoft, as both compiler companies raced to make their libraries supersets of the others libraries, so they could make the argument that their competitors compiler couldn't compile "standard" Windows source code. Contrary to popular opinion, it certainly was not a function in the libraries of "Wizard C", "Aztec C", "Lattice C", "Oregon C", "VAX C", or the majority of compilers that did not also have Windows versions. I also don't rememebr it on any of the 140+ UNIX platforms I've compiled code on in the last 20 years, with the exception of Linux (and I didn't inhale while using Linux). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 12:13:34 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 67BC5152B9 for ; Mon, 1 Nov 1999 12:13:26 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA07241 for ; Mon, 1 Nov 1999 21:13:24 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA75004 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 21:13:23 +0100 (MET) Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 0F86914A2F for ; Mon, 1 Nov 1999 12:11:36 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.1/8.9.1) id NAA55474; Mon, 1 Nov 1999 13:11:30 -0700 Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp05.primenet.com, id smtpday.5Ma; Mon Nov 1 13:11:22 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id NAA00533; Mon, 1 Nov 1999 13:11:23 -0700 (MST) From: Terry Lambert Message-Id: <199911012011.NAA00533@usr02.primenet.com> Subject: Re: Racing interrupts To: wes@softweyr.com (Wes Peters) Date: Mon, 1 Nov 1999 20:11:23 +0000 (GMT) Cc: tlambert@primenet.com, imp@village.org, freebsd-arch@freebsd.org In-Reply-To: <381B87A0.559C2CE7@softweyr.com> from "Wes Peters" at Oct 30, 99 06:04:48 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Terry Lambert wrote: > > > > Specifically, if the card has been correctly shut down before > > (or as a part of) the detach process, why would it generate > > an interrupt? > > The card eject notification. I understand that there be an interrupt for the eject. My question is "why an unfielded interrupt?"; sorry if that was not clear. I don't understand why the card services would not field that particular interrupt, unless the code was written incorrectly. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 12:14:40 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 66AF4150A2 for ; Mon, 1 Nov 1999 12:14:26 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA07261 for ; Mon, 1 Nov 1999 21:14:24 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA75037 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 21:14:24 +0100 (MET) Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by hub.freebsd.org (Postfix) with ESMTP id B58D615033 for ; Mon, 1 Nov 1999 12:13:39 -0800 (PST) (envelope-from gibbs@caspian.plutotech.com) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id MAA00659; Mon, 1 Nov 1999 12:14:23 -0700 (MST) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <199911011914.MAA00659@caspian.plutotech.com> X-Mailer: exmh version 2.1.0 09/18/1999 To: nate@mt.sri.com (Nate Williams) Cc: Peter Dufault , julian@whistle.com, freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-reply-to: Your message of "Mon, 01 Nov 1999 13:02:34 MST." <199911012002.NAA18614@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Nov 1999 12:14:22 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> > Thread share everything that a normal process, including a >> > thread-specific stack which is used to keep each thread's context >> > seperate from one another. >> >> I haven't caught up with you guys yet. This is what >> I asked about POSIX threading before: can stack be private per >> thread? > >I don't believe so, although each thread does have it's own stack, it's >not private. Sean would know more though.... What about thread local storage? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 12:14:56 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id BB5561503C for ; Mon, 1 Nov 1999 12:14:49 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA07267 for ; Mon, 1 Nov 1999 21:14:38 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA75050 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 21:14:38 +0100 (MET) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id B9D1714A2F; Mon, 1 Nov 1999 12:13:50 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id NAA15539; Mon, 1 Nov 1999 13:07:18 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd015400; Mon Nov 1 13:07:07 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id NAA00332; Mon, 1 Nov 1999 13:06:54 -0700 (MST) From: Terry Lambert Message-Id: <199911012006.NAA00332@usr02.primenet.com> Subject: Re: stpcpy() To: obrien@freebsd.org Date: Mon, 1 Nov 1999 20:06:51 +0000 (GMT) Cc: rjesup@wgate.com, freebsd-arch@freebsd.org In-Reply-To: <19991031230542.B10904@dragon.nuxi.com> from "David O'Brien" at Oct 31, 99 11:05:42 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I'll bet 95% of programmers working on systems where stpcpy has been > > part of the libraries for a long time don't even know that it isn't > > standard. > > I don't doubt that. Other than BDE and myself, I don't even know of > anyone that even has the ANSI-C standard. I have one (it's at home). Julian has one (it's in his cube). I think you would find that, out of all of the free OS communities, FreeBSD is probably the worst place you could pick to try to find people without copies of standards documents. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 12:17:35 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id F29D3152C6 for ; Mon, 1 Nov 1999 12:17:29 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA07320 for ; Mon, 1 Nov 1999 21:17:27 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA75097 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 21:17:26 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 8712115028; Mon, 1 Nov 1999 12:16:49 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id NAA17531; Mon, 1 Nov 1999 13:16:35 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA18763; Mon, 1 Nov 1999 13:16:34 -0700 Date: Mon, 1 Nov 1999 13:16:34 -0700 Message-Id: <199911012016.NAA18763@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: nate@mt.sri.com (Nate Williams), Peter Dufault , julian@whistle.com, freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: <199911011914.MAA00659@caspian.plutotech.com> References: <199911012002.NAA18614@mt.sri.com> <199911011914.MAA00659@caspian.plutotech.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> > Thread share everything that a normal process, including a > >> > thread-specific stack which is used to keep each thread's context > >> > seperate from one another. > >> > >> I haven't caught up with you guys yet. This is what > >> I asked about POSIX threading before: can stack be private per > >> thread? > > > >I don't believe so, although each thread does have it's own stack, it's > >not private. Sean would know more though.... > > What about thread local storage? I believe it's shared.... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 12:17:44 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3837B15028 for ; Mon, 1 Nov 1999 12:17:27 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA07313 for ; Mon, 1 Nov 1999 21:17:25 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA75083 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 21:17:25 +0100 (MET) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 1143A150A2; Mon, 1 Nov 1999 12:15:59 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id MAA10193; Mon, 1 Nov 1999 12:56:37 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd009893; Mon Nov 1 12:56:16 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id MAA29725; Mon, 1 Nov 1999 12:53:45 -0700 (MST) From: Terry Lambert Message-Id: <199911011953.MAA29725@usr02.primenet.com> Subject: GNU crap, in general (was stpcpy()) To: imp@village.org (Warner Losh) Date: Mon, 1 Nov 1999 19:53:45 +0000 (GMT) Cc: chris@calldei.com, obrien@freebsd.org, freebsd-arch@freebsd.org In-Reply-To: <199910291829.MAA89401@harmony.village.org> from "Warner Losh" at Oct 29, 99 12:29:38 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <19991029132257.A535@holly.calldei.com> Chris Costello writes: > : I'm seeing more and more of a need for a compat library for > : Linux and GNU software in general. Adding unnecessary bloat to > : our libc isn't necessary, in my opinion. > > The problem with this is that it becomes harder to build on FreeBSD > because you have to add additional, non-standard libraries to the > build process. This is the fault of the author of the tool, since > they used non-standard interfaces, so maybe it wouldn't be too bad. > The risk we run in not supporting them in libc is the perception that > FreeBSD isn't compatible (never mind what the sstandards say). > > We have similar issues with the long getopt stuff. I think it is a mistake to bring stuff that is not defined by standards into the nominally standards compliant parts of the source tree. This goes double for GNU "getopt", and other stuff that would take a serious reverse engineering effort to prove clean-room, without risking Stallman going off on a crusade, like his current crusade against the University of Michigan LDAP code's license, Mark Smith, and Tim Howes. There was a recent article in "BoardWatch" magazine that mentioned FreeBSD and Linux in the same breath as Solais and UnixWare, et. al., as what an ISP should be running on. One lament of the author was that the excellent FreeBSD ports system didn't work on platforms other than FreeBSD. While we can agree that this is a somewhat naieve comment for the author to have made, it is _very_ clear that the reason for this is, in many cases, use of GNU configure by the authors of the software making it nearly impossible to fully encapsulate the build process for multiple ports in a platform independant way... as opposed to the IMake method employed by most good X11 software, which allows the build to work in an intrinsically cross-platform way. Whether things like "configure" and "stpcpy" are reinvented out of plain ignorance, or they are being added to make the software Linux-centric out of malice, we would do well to take the high road, and avoid buying into these problems as much as possible. For stpcpy, if required by some package off the net, I believe the canonically correct thing to do is to provide an implementation as part of the source code for the software, giving the necessary changes back to the author, so that platforms which don't have the function can _all_ use the software, instead of limiting the software to FreeBSD and Linux, by adding stpcpy to a FreeBSD library. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 12:55:28 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id BB9E315329 for ; Mon, 1 Nov 1999 12:55:18 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA07819 for ; Mon, 1 Nov 1999 21:55:16 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA75308 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 21:55:16 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 23EAB152BF for ; Mon, 1 Nov 1999 12:38:42 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id PAA21506; Mon, 1 Nov 1999 15:36:34 -0500 (EST) Date: Mon, 1 Nov 1999 15:36:34 -0500 (EST) From: Daniel Eischen To: Nate Williams Cc: Peter Dufault , nate@mt.sri.com, julian@whistle.com, freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: <199911012002.NAA18614@mt.sri.com> 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, 1 Nov 1999, Nate Williams wrote: > > I asked about POSIX threading before: can stack be private per > > thread? > > I don't believe so, although each thread does have it's own stack, it's > not private. Sean would know more though.... If each threads stack was private, how would you pass objects allocated off the stack to other threads for processing? Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 12:55:56 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D5F22152B9 for ; Mon, 1 Nov 1999 12:55:43 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA07828 for ; Mon, 1 Nov 1999 21:55:35 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA75322 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 21:55:35 +0100 (MET) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 2E342152B9 for ; Mon, 1 Nov 1999 12:40:15 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40351>; Tue, 2 Nov 1999 07:34:44 +1100 Content-return: prohibited Date: Tue, 2 Nov 1999 07:40:02 +1100 From: Peter Jeremy Subject: Re: stpcpy() In-reply-to: To: freebsd-arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Nov2.073444est.40351@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <199910312349.CAA02684@tejblum.pp.ru> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Nov-01 12:24:10 +1100, Randell Jesup wrote: > I'll bet 95% of programmers working on systems where >stpcpy has been part of the libraries for a long time don't even know that >it isn't standard. If programmers expect to write portable code then they need to know what functions are standard. > I don't know about you, but I code for systems where >cutting CPU usage by 1% can actually make a real difference in the field >and to costs. Do you also factor in the extra maintenance costs associated with relying on non-standard functionality? > While non-ANSI standard, this particular function has been >virtually standard in PC compilers for a Long Time. I don't have it in front of me, but I'm fairly certain that my Amiga Lattice C manual lists it as a Lattice extension. Given that (AFAIK) M$ C started as Lattice C, I wouldn't be surprised if it started with Lattice. Matthew Dillon or bde (as long time compiler writers) might be able to offer further insight into its ancestry. > Like I said, near the >start of this, probably for more than a decade it's been in every >DOS/Win/Amiga/OS2/etc compiler I've used I don't recall ever seeing it in a Unix library (ignoring Linux for the time being) - which is probably more relevant here. stpcpy(3) on a local Linux system states: "This function is not part of the ANSI or POSIX standards, and is not customary on Unix systems, but is not a GNU invention either. Perhaps it comes from MS-DOS." Overall, I would not like to see stpcpy() appear in libc, though I have nothing against it being included in some compatibility library. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 12:57:26 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id CE9C415028 for ; Mon, 1 Nov 1999 12:57:18 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA07871 for ; Mon, 1 Nov 1999 21:57:16 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA75364 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 21:57:16 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id AB97A152FB; Mon, 1 Nov 1999 12:54:22 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id PAA23813; Mon, 1 Nov 1999 15:53:02 -0500 (EST) Date: Mon, 1 Nov 1999 15:53:02 -0500 (EST) From: Daniel Eischen To: Nate Williams Cc: "Justin T. Gibbs" , Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: <199911012002.NAA18597@mt.sri.com> 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, 1 Nov 1999, Nate Williams wrote: > > What about being able to push and pop cleanup handlers in the > > kernel? It's not quite as elegant as exception handlers, but > > would it accomplish what you want? > > I think the complexity would be much greater, but maybe I don't > understand fully what you are saying. > > Can you give a simple code example? see man pthread_cleanup_push(3). If a kernel thread were abnormally terminated it would run down its list of cleanup handlers to free held resources. Another method is to try and make resources knowledgeable about their owner(s), and for each thread to maintain a list of held resources. If a thread exits abnormally, it's easy enough to walk the list and free the held resources. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 13: 0:20 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 9481F14F02 for ; Mon, 1 Nov 1999 13:00:02 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA07904 for ; Mon, 1 Nov 1999 22:00:00 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA75429 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 21:59:59 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 63B6914F02; Mon, 1 Nov 1999 12:59:27 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id NAA18474; Mon, 1 Nov 1999 13:59:23 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA19090; Mon, 1 Nov 1999 13:59:22 -0700 Date: Mon, 1 Nov 1999 13:59:22 -0700 Message-Id: <199911012059.NAA19090@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Daniel Eischen Cc: Nate Williams , "Justin T. Gibbs" , Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: References: <199911012002.NAA18597@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > What about being able to push and pop cleanup handlers in the > > > kernel? It's not quite as elegant as exception handlers, but > > > would it accomplish what you want? > > > > I think the complexity would be much greater, but maybe I don't > > understand fully what you are saying. > > > > Can you give a simple code example? > > see man pthread_cleanup_push(3). If a kernel thread were abnormally > terminated it would run down its list of cleanup handlers to free > held resources. That's much more complicated that doing exception handling, since it's *very* obvious what happened when dealing with exceptions. Otherwise, you have to make some guesses as to which resource caused problems, and such. It might even be able to recover in some cases, depending on where the error occurred. This is how C++/Java do things, and it's very intuitive... (Modula-3 might also do this, but I'm not familiar enough with them to say with authority...) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 13: 5:16 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 220DC14CB6 for ; Mon, 1 Nov 1999 13:05:05 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA07990 for ; Mon, 1 Nov 1999 22:05:02 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA75474 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 22:05:02 +0100 (MET) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 9D75814EAD for ; Mon, 1 Nov 1999 13:03:48 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@d60-025.leach.ucdavis.edu [169.237.60.25]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id NAA37797; Mon, 1 Nov 1999 13:03:46 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id NAA38410; Mon, 1 Nov 1999 13:03:46 -0800 (PST) (envelope-from obrien) Date: Mon, 1 Nov 1999 13:03:46 -0800 From: "David O'Brien" To: Terry Lambert Cc: freebsd-arch@freebsd.org Subject: Re: stpcpy() Message-ID: <19991101130346.E808@dragon.nuxi.com> Reply-To: obrien@NUXI.com References: <19991031225429.A10904@dragon.nuxi.com> <199911012004.NAA00280@usr02.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <199911012004.NAA00280@usr02.primenet.com>; from tlambert@primenet.com on Mon, Nov 01, 1999 at 08:04:04PM +0000 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Yes. So what? You are suffering from the "NIH" disease. (BTW, stpcpy is > > > not first and is not GNUism/Linuxism). > > > > Then where did it come from? > > Borland Turbo-C, and thereafter it was quickly adopted by Microsoft, Do you have a date? GNU fileutils has a stpcpy.c file copyrighted 1989. -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 13:10:41 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 8505714E05 for ; Mon, 1 Nov 1999 13:10:28 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA08051 for ; Mon, 1 Nov 1999 22:10:25 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA75504 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 22:10:25 +0100 (MET) Received: from hda.hda.com (hda.bicnet.net [208.220.68.243]) by hub.freebsd.org (Postfix) with ESMTP id 489CC14DEA for ; Mon, 1 Nov 1999 13:09:52 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id QAA19039; Mon, 1 Nov 1999 16:04:29 -0500 (EST) From: Peter Dufault Message-Id: <199911012104.QAA19039@hda.hda.com> Subject: Re: Threads models and FreeBSD. In-Reply-To: from Daniel Eischen at "Nov 1, 99 03:36:34 pm" To: eischen@vigrid.com (Daniel Eischen) Date: Mon, 1 Nov 1999 16:04:28 -0500 (EST) Cc: arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG (I asked if the POSIX spec permitted private per-thread stack...) > If each threads stack was private, how would you pass objects allocated > off the stack to other threads for processing? You wouldn't, at least not with some flavor of mmap publishing and attaching that would probably open up your whole stack. I have no problem with that, especially in the kernel. I understand current practice may rule it out in a user library. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 13:20:30 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 8CBF314CC1 for ; Mon, 1 Nov 1999 13:20:08 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA08187 for ; Mon, 1 Nov 1999 22:20:05 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA75569 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 22:20:05 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 7A43314DEA; Mon, 1 Nov 1999 13:19:22 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id NAA62161; Mon, 1 Nov 1999 13:19:19 -0800 (PST) Date: Mon, 1 Nov 1999 13:19:19 -0800 (PST) From: Julian Elischer To: "Justin T. Gibbs" Cc: Nate Williams , Peter Dufault , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: <199911011914.MAA00659@caspian.plutotech.com> 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 there is no guarantee that thread specific storage is 'private' only that when you access it from each thread you end up pointing to a different place (physically). the use of an index register or some other trick satisfies this requirement. On Mon, 1 Nov 1999, Justin T. Gibbs wrote: > >> > Thread share everything that a normal process, including a > >> > thread-specific stack which is used to keep each thread's context > >> > seperate from one another. > >> > >> I haven't caught up with you guys yet. This is what > >> I asked about POSIX threading before: can stack be private per > >> thread? > > > >I don't believe so, although each thread does have it's own stack, it's > >not private. Sean would know more though.... > > What about thread local storage? > > -- > Justin > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 13:29:55 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id BF86414CC1 for ; Mon, 1 Nov 1999 13:29:44 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA08326 for ; Mon, 1 Nov 1999 22:29:42 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA75649 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 22:29:41 +0100 (MET) Received: from hda.hda.com (hda.bicnet.net [208.220.68.243]) by hub.freebsd.org (Postfix) with ESMTP id B91FA14F16 for ; Mon, 1 Nov 1999 13:28:31 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id QAA19094; Mon, 1 Nov 1999 16:22:24 -0500 (EST) From: Peter Dufault Message-Id: <199911012122.QAA19094@hda.hda.com> Subject: Re: Threads models and FreeBSD. In-Reply-To: <199911012104.QAA19039@hda.hda.com> from Peter Dufault at "Nov 1, 99 04:04:28 pm" To: dufault@hda.com (Peter Dufault) Date: Mon, 1 Nov 1999 16:22:24 -0500 (EST) Cc: arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > You wouldn't, at least not with some flavor of mmap publishing and > attaching that would probably open up your whole stack. Should read: "not with out some flavor of mmap" Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 13:36:22 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 1F2D814E4A for ; Mon, 1 Nov 1999 13:36:04 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA08392 for ; Mon, 1 Nov 1999 22:35:57 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA75701 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 22:35:57 +0100 (MET) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (Postfix) with ESMTP id AB9C914E36 for ; Mon, 1 Nov 1999 13:35:26 -0800 (PST) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.3/8.9.1) id IAA66409; Tue, 2 Nov 1999 08:44:49 +1100 (EST) (envelope-from jb) Date: Tue, 2 Nov 1999 08:44:49 +1100 From: John Birrell To: Peter Dufault Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads goals version III Message-ID: <19991102084448.A66172@freebsd1.cimlogic.com.au> References: <199911011233.HAA17742@hda.hda.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <199911011233.HAA17742@hda.hda.com>; from Peter Dufault on Mon, Nov 01, 1999 at 07:33:52AM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Nov 01, 1999 at 07:33:52AM -0500, Peter Dufault wrote: > > 4/ All threads in a processs see the same address space (exactly). > > Stacks too? Is that a rule implied from POSIX or one for portability? I think so. There is nothing to stop a thread from passing a pointer to something on it's stack to another thread, assuming that it will ensure that the stack will remain valid. This is common practice where one thread parents one or more child threads and wishes to share information with them. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ john.birrell@cai.com john.birrell@opendirectory.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 13:38:56 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id B3B2014E2A for ; Mon, 1 Nov 1999 13:38:48 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA08432 for ; Mon, 1 Nov 1999 22:38:46 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA75732 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 22:38:46 +0100 (MET) Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 2FE7314E2A for ; Mon, 1 Nov 1999 13:38:17 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id QAA09617 for ; Mon, 1 Nov 1999 16:33:35 -0500 (EST) Reply-To: Randell Jesup To: freebsd-arch@freebsd.org Subject: Compatibility libraries References: <199910312349.CAA02684@tejblum.pp.ru> <99Nov2.073444est.40351@border.alcanet.com.au> From: Randell Jesup Date: 01 Nov 1999 17:34:44 +0000 In-Reply-To: Peter Jeremy's message of "Tue, 2 Nov 1999 07:40:02 +1100" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Jeremy writes: >> While non-ANSI standard, this particular function has been >>virtually standard in PC compilers for a Long Time. > >I don't have it in front of me, but I'm fairly certain that my >Amiga Lattice C manual lists it as a Lattice extension. Given >that (AFAIK) M$ C started as Lattice C, I wouldn't be surprised >if it started with Lattice. Matthew Dillon or bde (as long time >compiler writers) might be able to offer further insight into >its ancestry. Yes, I think it did start in Lattice (later SAS, then Lattice again). I should ask John Toebes, one of the former SAS/Lattice compiler people. I think a number of other popular DOS/Win/OS2 compilers added it also. It might have originated there, though I think I remember a reference to it in Dr. Dobbs in an article by Tom Holub back around '84-85ish (on a pseudo-Cshell implementation?) I seem (vaguely) to remember him saying that stpcpy made a measurable difference in a pass of the compiler (preprocessor I suspect). Also this was admittedly on a 7MHz 68000 platform. >I don't recall ever seeing it in a Unix library (ignoring Linux for >the time being) - which is probably more relevant here. True. >Overall, I would not like to see stpcpy() appear in libc, though I >have nothing against it being included in some compatibility library. I bow to the assembled opinions and agree. I'd thought it was a bit more ubiquitous than it is, given it's in Linux now. So, what additional libraries should we have, and what should be in them? I don't like the "add the code to each port" solution a lot, since unless the code is standardized, there's a considerable chance for Stupid Coding Mistakes, not to mention potentially lots of time for the porter to write (or track down) the source for various portability functions. Sounds like a good case for libraries. Alternatively, we could have standardized source-code libraries for use by porters. The downside is that bugfixes and implementation updates to match the underlying OS become a PAIN to integrate; and to a lesser extent runtime-bloat. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 13:59:27 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 1AF0214E2A for ; Mon, 1 Nov 1999 13:59:13 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA08691 for ; Mon, 1 Nov 1999 22:59:09 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA75851 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 22:59:09 +0100 (MET) Received: from hda.hda.com (hda.bicnet.net [208.220.68.243]) by hub.freebsd.org (Postfix) with ESMTP id BE19E14EAD for ; Mon, 1 Nov 1999 13:58:52 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id QAA19185; Mon, 1 Nov 1999 16:53:11 -0500 (EST) From: Peter Dufault Message-Id: <199911012153.QAA19185@hda.hda.com> Subject: Re: Threads goals version III In-Reply-To: <19991102084448.A66172@freebsd1.cimlogic.com.au> from John Birrell at "Nov 2, 99 08:44:49 am" To: jb@cimlogic.com.au (John Birrell) Date: Mon, 1 Nov 1999 16:53:10 -0500 (EST) Cc: dufault@hda.com, julian@whistle.com, freebsd-arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, Nov 01, 1999 at 07:33:52AM -0500, Peter Dufault wrote: > > > 4/ All threads in a processs see the same address space (exactly). > > > > Stacks too? Is that a rule implied from POSIX or one for portability? > > I think so. There is nothing to stop a thread from passing a pointer > to something on it's stack to another thread, assuming that it will > ensure that the stack will remain valid. This is common practice where > one thread parents one or more child threads and wishes to share > information with them. Obviously he can't return though. Here's what I would argue for in setting a standards document: main() { int mainvar; newthread(t1); /* t1 is a thread and it can access mainvar... */ sub(); } sub() { int subvar; newthread(t2); /* t2 can access subvar or mainvar, but maybe * t1 can't access subvar. * Maybe the stack just crossed a page boundary. */ while(1) keep_stack_context(); } Essentially threads would only be guaranteed access to stack variables both in existence and valid when the thread is created. All stack growth can be in separate address spaces. If a stackless main() creates a bunch of threads at that level and then idles those threads would have completely disjoint stacks. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 14: 4:30 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id E926B14E2A for ; Mon, 1 Nov 1999 14:04:25 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA08762 for ; Mon, 1 Nov 1999 23:04:24 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA75930 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 23:04:24 +0100 (MET) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 7ABC7152BF for ; Mon, 1 Nov 1999 14:02:33 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id PAA02106; Mon, 1 Nov 1999 15:02:01 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpdAAA5Vay6d; Mon Nov 1 15:01:49 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id PAA05490; Mon, 1 Nov 1999 15:02:14 -0700 (MST) From: Terry Lambert Message-Id: <199911012202.PAA05490@usr02.primenet.com> Subject: Re: stpcpy() To: obrien@NUXI.com Date: Mon, 1 Nov 1999 22:02:14 +0000 (GMT) Cc: tlambert@primenet.com, freebsd-arch@freebsd.org In-Reply-To: <19991101130346.E808@dragon.nuxi.com> from "David O'Brien" at Nov 1, 99 01:03:46 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > Yes. So what? You are suffering from the "NIH" disease. (BTW, stpcpy is > > > > not first and is not GNUism/Linuxism). > > > > > > Then where did it come from? > > > > Borland Turbo-C, and thereafter it was quickly adopted by Microsoft, > > Do you have a date? GNU fileutils has a stpcpy.c file copyrighted 1989. 1986. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 14:31:46 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 7C81814A0E for ; Mon, 1 Nov 1999 14:31:40 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA09003 for ; Mon, 1 Nov 1999 23:31:38 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA76101 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 23:31:37 +0100 (MET) Received: from mail.rdc2.on.home.com (ha1.rdc2.on.home.com [24.9.0.15]) by hub.freebsd.org (Postfix) with ESMTP id 591F9152C6 for ; Mon, 1 Nov 1999 14:30:00 -0800 (PST) (envelope-from street@iname.com) Received: from mired.eh.local ([24.64.136.188]) by mail.rdc2.on.home.com (InterMail v4.01.01.07 201-229-111-110) with ESMTP id <19991101223000.NYVN3040.mail.rdc2.on.home.com@mired.eh.local>; Mon, 1 Nov 1999 14:30:00 -0800 Received: (from kws@localhost) by mired.eh.local (8.9.3/8.9.3) id RAA82710; Mon, 1 Nov 1999 17:29:59 -0500 (EST) (envelope-from kws) To: obrien@NUXI.com Cc: Terry Lambert , freebsd-arch@freebsd.org Subject: Re: stpcpy() References: <19991031225429.A10904@dragon.nuxi.com> <199911012004.NAA00280@usr02.primenet.com> <19991101130346.E808@dragon.nuxi.com> From: Kevin Street Date: 01 Nov 1999 17:29:59 -0500 In-Reply-To: "David O'Brien"'s message of "Mon, 1 Nov 1999 13:03:46 -0800" Message-ID: <87puxt976g.fsf@mired.eh.local> Lines: 17 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Biscayne" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "David O'Brien" writes: > > > > Yes. So what? You are suffering from the "NIH" disease. (BTW, stpcpy is > > > > not first and is not GNUism/Linuxism). > > > > > > Then where did it come from? > > > > Borland Turbo-C, and thereafter it was quickly adopted by Microsoft, > > Do you have a date? GNU fileutils has a stpcpy.c file copyrighted 1989. I have a Borland Turbo C V2 manual copyright 1988 with stpcpy in it. I don't think I have a V1 manual to check. -- Kevin Street street@iname.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 14:34: 9 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 8D49E14A0E for ; Mon, 1 Nov 1999 14:34:05 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA09033 for ; Mon, 1 Nov 1999 23:34:04 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA76128 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 23:34:04 +0100 (MET) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id F1AEB14A0E for ; Mon, 1 Nov 1999 14:33:38 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id PAA62789; Mon, 1 Nov 1999 15:33:34 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id PAA09446; Mon, 1 Nov 1999 15:35:46 -0700 (MST) Message-Id: <199911012235.PAA09446@harmony.village.org> To: Terry Lambert Subject: Re: Racing interrupts Cc: wes@softweyr.com (Wes Peters), freebsd-arch@freebsd.org In-reply-to: Your message of "Mon, 01 Nov 1999 20:11:23 GMT." <199911012011.NAA00533@usr02.primenet.com> References: <199911012011.NAA00533@usr02.primenet.com> Date: Mon, 01 Nov 1999 15:35:46 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199911012011.NAA00533@usr02.primenet.com> Terry Lambert writes: : My question is "why an unfielded interrupt?"; sorry if that was : not clear. I don't understand why the card services would not : field that particular interrupt, unless the code was written : incorrectly. The card services do not install interrupts for the cards in question. The drivers for the cards do that. There are two interrupts generated, at least on my machine, one for the card eject on the interrupt channel assigned to the bridge and another one for the card on the interrupt assigned to the card when the power is removed from the card (at least that's my interpretation of the stack traces I've looked at). Since the driver has been detached from the driver tree, that latter interrupt is unfielded unless the bridge driver listens for the card to release the interrupt and it installs its own nop interrupt handler. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 14:43:51 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0BFE714DC4 for ; Mon, 1 Nov 1999 14:43:48 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA09228 for ; Mon, 1 Nov 1999 23:43:47 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA76234 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 23:43:47 +0100 (MET) Received: from gw.nectar.com (gw.nectar.com [209.98.143.44]) by hub.freebsd.org (Postfix) with ESMTP id D95A514E42 for ; Mon, 1 Nov 1999 14:43:32 -0800 (PST) (envelope-from nectar@nectar.com) Received: from bone.nectar.com (bone.nectar.com [10.0.0.105]) by gw.nectar.com (Postfix) with ESMTP id 29A18C009; Mon, 1 Nov 1999 16:42:13 -0600 (CST) Received: from bone.nectar.com (localhost [127.0.0.1]) by bone.nectar.com (Postfix) with ESMTP id 093401DA4; Mon, 1 Nov 1999 16:43:28 -0600 (CST) X-Mailer: exmh version 2.1.0 09/18/1999 X-PGP-RSAfprint: 00 F9 E6 A2 C5 4D 0A 76 26 8B 8B 57 73 D0 DE EE X-PGP-RSAkey: http://www.nectar.com/nectar-rsa.txt X-PGP-DSSfprint: AB2F 8D71 A4F4 467D 352E 8A41 5D79 22E4 71A2 8C73 X-PGP-DHfprint: 2D50 12E5 AB38 60BA AF4B 0778 7242 4460 1C32 F6B1 X-PGP-DH-DSSkey: http://www.nectar.com/nectar-dh-dss.txt From: Jacques Vidrine To: Julian Elischer Cc: freebsd-arch@freebsd.org In-reply-to: References: Subject: Re: Threads models and FreeBSD. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Nov 1999 16:43:27 -0600 Message-Id: <19991101224328.093401DA4@bone.nectar.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 31 October 1999 at 13:15, Julian Elischer wrote: [snip] > 3/ Inability of one thread to block aother thread unless they are > intentionally synchronising. Do we mean: Threads can block (e.g. in the kernel) independently of the execution of other threads in the same process? > 5/ All threads share the same file resources. The resources shared among threads in the same process should be configurable. The file descriptors, resource limits, credentials, address space, and so forth should be shared, unless otherwise specified at the time of the creation of the thread. Um, of course it doesn't make a whole lot of sense to NOT share the address space :-) -- Jacques Vidrine / n@nectar.com / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 15:18:53 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D407014E01 for ; Mon, 1 Nov 1999 15:18:48 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA09673 for ; Tue, 2 Nov 1999 00:18:47 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA76489 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 00:18:46 +0100 (MET) Received: from io.yi.org (24.66.174.118.bc.wave.home.com [24.66.174.118]) by hub.freebsd.org (Postfix) with ESMTP id CC69A156A8 for ; Mon, 1 Nov 1999 15:17:36 -0800 (PST) (envelope-from jake@checker.org) Received: from io.yi.org (localhost [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id F30501FD7; Mon, 1 Nov 1999 15:17:42 -0800 (PST) X-Mailer: exmh version 2.1.0 09/18/1999 To: Peter Dufault Cc: freebsd-arch@freebsd.org Subject: Re: Threads goals version III In-reply-to: Your message of "Mon, 01 Nov 1999 16:53:10 EST." <199911012153.QAA19185@hda.hda.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Nov 1999 15:17:42 -0800 From: Jake Burkholder Message-Id: <19991101231743.F30501FD7@io.yi.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Obviously he can't return though. Here's what I would > argue for in setting a standards document: > > main() > { > int mainvar; > > newthread(t1); /* t1 is a thread and it can access mainvar... */ > > sub(); > } > > sub() > { > int subvar; > > newthread(t2); /* t2 can access subvar or mainvar, but maybe > * t1 can't access subvar. > * Maybe the stack just crossed a page boundary. > */ > > while(1) > keep_stack_context(); > } > I think there's confusion here, forking a new thread is not like forking a new process. A start routine needs to be passed in and a new stack and context setup, so the thread begins execution as if start_routine were its "main". See Daniel's {get,set,make,swap}context diffs. I supposed that newthread(t1) could mean that there is now a new thread, which starts executing at the point newthread was called (in main), only on a new stack, but that doesn't seem to me to be the way it is commonly implemented. int global; /* all threads can access this */ main() { thread t1; int mainvar; /* this could also be mmaped or stack based storage */ t.stack = malloc(some memory); new_thread(&t1, foo, 1, &mainvar); sub(); wait(t1); } sub() { thread t2; int subvar; /* t1 has no access to this at all */ new_thread(&t2, foo, 1, &subvar); wait(t2); } foo(int ac, ...) { int *p; va_list ap; assert(ac == 1); va_start(ap, ac); p = va_arg(ap, int *) va_end(ap); /* t1 now has access to mainvar through p */ /* t2 now has access to subvar through p */ } The WHOLE address space is shared. You can pass around pointers to stack based storage, but a new thread executes a new start_routine, so it can't access variables from the scope in which new_thread was called, only what get passed into start_routine. At least that is my understanding. Apologies if I misinterpreted what you were trying to say. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 16:32:26 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id F126A14DC4 for ; Mon, 1 Nov 1999 16:32:21 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id BAA10191 for ; Tue, 2 Nov 1999 01:32:20 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA76767 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 01:32:19 +0100 (MET) Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 88E3414DC4 for ; Mon, 1 Nov 1999 16:31:57 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id TAA15398 for ; Mon, 1 Nov 1999 19:27:17 -0500 (EST) Reply-To: Randell Jesup To: freebsd-arch@freebsd.org Subject: Re: Threads goals version III References: <19991101231743.F30501FD7@io.yi.org> From: Randell Jesup Date: 01 Nov 1999 20:28:26 +0000 In-Reply-To: Jake Burkholder's message of "Mon, 01 Nov 1999 15:17:42 -0800" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jake Burkholder writes: >int global; /* all threads can access this */ > >main() { > thread t1; > int mainvar; > > /* this could also be mmaped or stack based storage */ > t.stack = malloc(some memory); What's this for? Wouldn't each new thread have it's own stack space allocated by the thread library/kernel? (Perhaps according to size requests in new_thread, or just an automatically grown segment of the process (not thread) VM space.) Note: I haven't looked at Unix thread library details. > new_thread(&t1, foo, 1, &mainvar); >foo(int ac, ...) { > /* t1 now has access to mainvar through p */ > >The WHOLE address space is shared. You can pass around >pointers to stack based storage, but a new thread executes >a new start_routine, so it can't access variables from the >scope in which new_thread was called, only what get passed >into start_routine. Also, inter-thread IPC and implicit shared structures might include pointers to stack variables, such as for a synchronous request from another thread for data to be put into a buffer on the stack, such as: (pseudo-code) void bar(unsigned char *encoded_data, unsigned long encoded_data_len) { unsigned char buffer[1000]; msg->out_buffer = &buffer[0]; msg->out_buflen = sizeof(buffer); msg->in_buffer = encoded_data; msg->in_buflen = encoded_data_len; msg->command = DECODE_DATA; // do_message is synchronous, sends a message and waits for a reply do_message(decode_thread,msg); // do something with buffer data } What synchronization (semaphores, etc) and inter-thread messaging mechanisms are we thinking of? -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 16:36:47 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 7B42D14DC4 for ; Mon, 1 Nov 1999 16:36:41 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id BAA10246 for ; Tue, 2 Nov 1999 01:36:40 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA76839 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 01:36:40 +0100 (MET) Received: from arc.hq.cti.ru (arc.hq.cti.ru [195.34.40.3]) by hub.freebsd.org (Postfix) with ESMTP id 484AA15357 for ; Mon, 1 Nov 1999 16:33:57 -0800 (PST) (envelope-from dima@tejblum.pp.ru) Received: (from uucp@localhost) by arc.hq.cti.ru (8.9.3/8.9.3) with UUCP id DAA38703; Tue, 2 Nov 1999 03:33:41 +0300 (MSK) (envelope-from dima@tejblum.pp.ru) Received: from tejblum.pp.ru (localhost [127.0.0.1]) by tejblum.pp.ru (8.9.3/8.9.3) with ESMTP id DAA03010; Tue, 2 Nov 1999 03:40:22 +0300 (MSK) (envelope-from dima@tejblum.pp.ru) Message-Id: <199911020040.DAA03010@tejblum.pp.ru> X-Mailer: exmh version 2.0gamma 1/27/96 To: Warner Losh Cc: freebsd-arch@freebsd.org From: Dmitrij Tejblum Subject: Re: stpcpy() In-reply-to: Your message of "Sun, 31 Oct 1999 23:05:45 MST." <199911010605.XAA04972@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Nov 1999 03:40:22 +0300 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > For example, the following program is strictly standards conforming, > but would break if we added this change: [example snipped]. s/stpcpy/index/g, and you will get a strictly standard conforming program that already broken on FreeBSD. A random programmer will much more likely name his function `index' than `stpcpy'. Anyhow, if a program is actually standard conforming, it should be compiled with -D_ANSI_SOURCE or -D_POSIX_SOURCE (depending on the standard it conform to), and still work fine. That is, you are _wrong_, no conforming program would break. Some non-conforming programs may break, but it is their fault :-). > Just because it is in every compiler you have ever used doesn't make > it desirable to have it our libc. Just because it is useful (and being used) make it desirable to have it in our libc. (Then, after another 20 or so years, stpcpy() will be in the standard. :-) This is the purpose of the C language - be convenient.) Dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 16:36:54 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A23E415349 for ; Mon, 1 Nov 1999 16:36:49 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id BAA10253 for ; Tue, 2 Nov 1999 01:36:48 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA76853 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 01:36:48 +0100 (MET) Received: from arc.hq.cti.ru (arc.hq.cti.ru [195.34.40.3]) by hub.freebsd.org (Postfix) with ESMTP id 3A98B15329 for ; Mon, 1 Nov 1999 16:34:56 -0800 (PST) (envelope-from dima@tejblum.pp.ru) Received: (from uucp@localhost) by arc.hq.cti.ru (8.9.3/8.9.3) with UUCP id DAA38725; Tue, 2 Nov 1999 03:34:10 +0300 (MSK) (envelope-from dima@tejblum.pp.ru) Received: from tejblum.pp.ru (localhost [127.0.0.1]) by tejblum.pp.ru (8.9.3/8.9.3) with ESMTP id DAA03020; Tue, 2 Nov 1999 03:40:35 +0300 (MSK) (envelope-from dima@tejblum.pp.ru) Message-Id: <199911020040.DAA03020@tejblum.pp.ru> X-Mailer: exmh version 2.0gamma 1/27/96 To: obrien@NUXI.com Cc: Dmitrij Tejblum , freebsd-arch@freebsd.org From: Dmitrij Tejblum Subject: Re: stpcpy() In-reply-to: Your message of "Sun, 31 Oct 1999 16:02:55 PST." <19991031160255.E2388@relay.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain Date: Tue, 02 Nov 1999 03:40:34 +0300 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "David O'Brien" wrote: > On Mon, Nov 01, 1999 at 02:49:24AM +0300, Dmitrij Tejblum wrote: > > > Bruce hit the nail right on the head -- people are making assumptions > > > with out know what their compiler is doing. > > > > You omitted following Bruce's words: > > > > > > In practice, gcc seems to only inline strlen(). > > What does that have to do with the wisdom I was extracting from BDE's > statements? A LOT of people are trying to optimize things with out > knowing what their compiler does. That do mostly defeat this "wisdom" in this particular case. The part you quoted talked about an imaginary compiler. As I wrote in the previous mail, on a real non-braindamaged compiler stpcpy() cannot be slower than the strcpy()/strlen() combination. It is quite obvious for any professional programmer. > > Really? Why? My colleagues use Windows and occasionally use stpcpy(), > > just because it is CONVENIENT and obviously cannot make their program > > slower. If the program is slower on FreeBSD (or even not compile), this is > > not their fault. > > Bull crap. If an application writer uses non-standard functions it *is* > their fault. Next day you will tell us to not use strdup(). Don't make me laugh. Dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 23: 9: 4 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 8B70014CB6 for ; Mon, 1 Nov 1999 23:08:57 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id IAA13034 for ; Tue, 2 Nov 1999 08:08:50 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA78079 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 08:08:50 +0100 (MET) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (Postfix) with ESMTP id 0839F14CB6 for ; Mon, 1 Nov 1999 23:08:31 -0800 (PST) (envelope-from michael.schuster@germany.sun.com) Received: from emuc05-home.Germany.Sun.COM ([129.157.51.10]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA07672; Mon, 1 Nov 1999 23:08:28 -0800 (PST) Received: from germany.sun.com (hacker [129.157.167.97]) by emuc05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with ESMTP id IAA10047; Tue, 2 Nov 1999 08:08:26 +0100 (MET) Message-ID: <381E8DEC.743798DC@germany.sun.com> Date: Tue, 02 Nov 1999 08:08:28 +0100 From: Michael Schuster - TSC SunOS Germany Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert , freebsd-arch@freebsd.org Subject: Re: GNU crap, in general (was stpcpy()) References: <199911011953.MAA29725@usr02.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > I think it is a mistake to bring stuff that is not defined by > standards into the nominally standards compliant parts of the > source tree. > ... > For stpcpy, if required by some package off the net, I believe > the canonically correct thing to do is to provide an implementation > as part of the source code for the software, giving the necessary > changes back to the author, so that platforms which don't have > the function can _all_ use the software, instead of limiting the > software to FreeBSD and Linux, by adding stpcpy to a FreeBSD library. > > Terry Lambert > terry@lambert.org I couldn't agree more. regards Michael -- Michael Schuster / Michael.Schuster@germany.sun.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 23:15:59 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 5AA5814EC7 for ; Mon, 1 Nov 1999 23:15:52 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id IAA13092 for ; Tue, 2 Nov 1999 08:15:51 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA78108 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 08:15:50 +0100 (MET) Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 418AD14EC7 for ; Mon, 1 Nov 1999 23:15:29 -0800 (PST) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id RAA09450; Tue, 2 Nov 1999 17:45:03 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3.1 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <381E8DEC.743798DC@germany.sun.com> Date: Tue, 02 Nov 1999 17:45:02 +0930 (CST) From: "Daniel O'Connor" To: Michael Schuster - TSC SunOS Germany Subject: Re: GNU crap, in general (was stpcpy()) Cc: freebsd-arch@freebsd.org, Terry Lambert Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 02-Nov-99 Michael Schuster - TSC SunOS Germany wrote: > > changes back to the author, so that platforms which don't have > > the function can _all_ use the software, instead of limiting the > > software to FreeBSD and Linux, by adding stpcpy to a FreeBSD library. > I couldn't agree more. Well since the mountain isn't going to move to Mohammedwe could at least provide a port, or put it in compat somewhere. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 1 23:16:11 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 5FFAB14CB6 for ; Mon, 1 Nov 1999 23:16:06 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id IAA13100 for ; Tue, 2 Nov 1999 08:16:05 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA78122 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 08:16:04 +0100 (MET) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (Postfix) with ESMTP id D6CEC14CB6 for ; Mon, 1 Nov 1999 23:15:50 -0800 (PST) (envelope-from michael.schuster@germany.sun.com) Received: from emuc05-home.Germany.Sun.COM ([129.157.51.10]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA09078; Mon, 1 Nov 1999 23:15:47 -0800 (PST) Received: from germany.sun.com (hacker [129.157.167.97]) by emuc05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with ESMTP id IAA10707; Tue, 2 Nov 1999 08:15:46 +0100 (MET) Message-ID: <381E8FA4.CF60DD7D@germany.sun.com> Date: Tue, 02 Nov 1999 08:15:48 +0100 From: Michael Schuster - TSC SunOS Germany Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert , freebsd-arch@freebsd.org Subject: Re: stpcpy() References: <199911011936.MAA29291@usr02.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > I really think 99% of the programs using stpcpy() for "speed" reasons > > would spend 99% of their time elsewhere if p=strchr(strcpy(d,s), '\0'); > > were used. > > I believe the point is to iterate the string once, instead of twice, > without having to learn how to use pointers yourself. I have to contradict you here: I do not believe that C is the right language to use if you're not prepared to learn about pointers _in_depth_. This may be lamentable, but it's a fact. Iterating a string only once, instead of twice, is a different point, one I'd be prepared to concede. > Terry Lambert > terry@lambert.org cheers Michael -- Michael Schuster / Michael.Schuster@germany.sun.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 1: 0:33 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 28A8614E79 for ; Tue, 2 Nov 1999 01:00:21 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id KAA14702 for ; Tue, 2 Nov 1999 10:00:18 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA78400 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 10:00:17 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 536DE14F34 for ; Tue, 2 Nov 1999 00:59:30 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id AAA79439 for ; Tue, 2 Nov 1999 00:59:28 -0800 (PST) Date: Tue, 2 Nov 1999 00:59:28 -0800 (PST) From: Julian Elischer To: freebsd-arch@freebsd.org Subject: Threads models and FreeBSD. (Next Step) 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 Here is an updated version of the rather simplistic requirements for a threads model for freeBSD. New requirements can be added as we go along but these should give us tomething to go on.. Now, we need to start collecting alternative implementations that might satisfy these goals. We should gathe rinformation on these and READ teh literature and code, before discussinghtese too much. getting into arguments at this stage will not help the process. We have 4 starters at this point. Note, they MAY NOT BE mutually exclusive! 1/ The scheme we've been working towards for a while due to lack of suggested alternatives.. rfork based processes sharing resources. This is very similar to the Linuxthreads implementation. one kernel schedulable entity (light process) per thread. 1A/ actually use the linuxthread code.. 2/ A variant of (1) where blocking processes somehow signal a userland action that starts another thread in another rfork'd process. I have heard rumours that someone was looking at this. Could they own up? 3/ The much referenced paper on "Scheduler activations" Everyone should read this paper as homework (It's referenced below) before participating further in this disussion. 4/ Terry's schem. (similar in some ways to (3) but not the same.. TERRY's homework is to write it down. 5/ Any more schemes paple know of, can go here. julian [1st reposting, (with changes)] ------------------------------------ This article will be reposted again for late comers in the discussion thread: There are several properties of threads that make them both good and bad programming models. John Ousterhout gave a keynote at Usenix a couple of years ago titled "threads considered harmful", which was both ammusing and had more that a shred of truth to it. Having said that, good thread support is essential able to support a lot of modern programs, and is a good way of ensuring that processes can make use of the increasing amount of MP machinery that is available. So what are the definitions that a thread enabled environment should possess? This not a definative list, and before we go on to solve the worlds threading problems, I'd like everyone to add their thoughts to this list so that we can agree about what problems we are trying to solve. If you are going to say "support pthreads" I'd like you to instead break that down to what we need to have in order to support pthreads.. I want pthreads to be a by-product (almost) of a good threading model, not the design goal. -------------------------------------------------------------- 1/ Multiple independent 'threads of control' within a single process at user level. The most basic quality of threads. 2/ Ability to simultaneously schedule M threads over N Processors, and have min(M,N) threads simultaneously executing. 2A/ ability to tune and control the above.. 3/ just because one thread blocks, doesn't mean that the others can't keep running. 4/ All threads in a processs see the same address space (exactly). 5/ All threads in a process share the same system resources. 6/ (contentious) multiple theads should be bound to within the resource limits of the single process. 7/ Some well documeted scheme exists for handling signals and other async events. 8/ Exit/shutdown protocol is well defined. 9/ there exists a set of primatives that allow threads to influence the in-process scheduling between themselves. 9A/ e.g. 'per thread' Thread scheduling classes. 10/ Quick access to curthread and thread specific data. 11/ A method to ask a thread blocked in the kernel to wake up and back out. (similar to present 'signals') 12/ Processorr affinity for threads. ---- possible userland implementation goals----- 1/ A libpthread that can be linked with libc. 2/ Libc needs to change so that library functions and system calls used internal to the library do not use the externally visible cancellable equivalents. ------------- Meta-goals ----------- We should keep our eyes on: *) scalability *) performance *) ability to support features required by standards based threads. *) ability to support features of those therad packages we select as needed. --- refs: http://www.freebsd.org/~deischen/p95-anderson.pdf http://www.freebsd.org/cgi/getmsg.cgi?fetch=25000+30231+/usr/local/www/db/text/1 999/freebsd-current/19990321.freebsd-current http://lt.tar.com/ ------------------------------------- ------------- What we have at the moment: John Birrell's excelent work on user-level threading (libc_r), based originally on Chris provenzo's threading code has given us quite a bit of mileage so far, but it's starting to run out of steam with new requirements being more certain about kernel support requirements. It is notable that we already support Linux kernel threads on FreeBSD better than we support a native threads model. This is because we support the 'clone' system call through our rfork() code, and that is their basis for threading. As is common for this group of people, we have not adopted the Linux approach because it is considered to be 'too simplistic', assigning a separate kernel schedulable process to run each thread. Having said that, Amancio Hasty at one stage wrote a set of threading primitives to allow Kafe to run on FreeBSD using this scheme of threading, and Richard Seaman has a port of the Linuxthreads code to freeBSD at his website, http://lt.tar.com/ . This represents a useful piece of work and though it is presently not working on -current, hopefully this will be fixed soon. I believe there may be problems with the new signal stuff though I have not tested it myself. I also reference the following email in the archives: http://www.freebsd.org/cgi/getmsg.cgi?fetch=25000+30231+/usr/local/www/db/text/1999/freebsd-current/19990321.freebsd-current Peter dufault also has some work on scheduling that may be slightly relevent. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 4:21:53 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 08BC914DFC for ; Tue, 2 Nov 1999 04:21:43 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA18187 for ; Tue, 2 Nov 1999 13:21:40 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA79290 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 13:21:40 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id DD1D214DFC for ; Tue, 2 Nov 1999 04:21:14 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt21.pcnet.net [206.105.29.95]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id HAA07165; Tue, 2 Nov 1999 07:19:52 -0500 (EST) Message-ID: <381ED720.5A24A02B@vigrid.com> Date: Tue, 02 Nov 1999 07:20:48 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > Here is an updated version of the rather simplistic requirements for a > threads model for freeBSD. [...] > > 1/ Multiple independent 'threads of control' within a single process > at user level. The most basic quality of threads. > > 2/ Ability to simultaneously schedule M threads over N Processors, > and have min(M,N) threads simultaneously executing. Shouldn't this be M threads over N [lightweight] Processes? > 6/ (contentious) multiple theads should be bound to within the resource > limits of the single process. Disagree. I want lightweight processes to have their own quantum not limited (in total) to the parent process quantum. > ------------- > Meta-goals > ----------- > We should keep our eyes on: > *) scalability > *) performance > *) ability to support features required by standards based threads. > *) ability to support features of those therad packages we select as > needed. How about [from the "scheduler activations" paper] Flexibility? > > refs: > http://www.freebsd.org/~deischen/p95-anderson.pdf > http://www.freebsd.org/cgi/getmsg.cgi?fetch=25000+30231+/usr/local/www/db/text/1 > 999/freebsd-current/19990321.freebsd-current > http://lt.tar.com/ Do you want other references? I know there are several available papers on Solaris multi-threading. There are also papers on locking mechanisms. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 4:24:52 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id B4FC014DFC for ; Tue, 2 Nov 1999 04:24:44 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA18231 for ; Tue, 2 Nov 1999 13:24:42 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA79316 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 13:24:42 +0100 (MET) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 7405D14DFC for ; Tue, 2 Nov 1999 04:24:21 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id NAA25552; Tue, 2 Nov 1999 13:24:02 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Daniel M. Eischen" Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) In-reply-to: Your message of "Tue, 02 Nov 1999 07:20:48 EST." <381ED720.5A24A02B@vigrid.com> Date: Tue, 02 Nov 1999 13:24:02 +0100 Message-ID: <25550.941545442@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <381ED720.5A24A02B@vigrid.com>, "Daniel M. Eischen" writes: >> 6/ (contentious) multiple theads should be bound to within the resource >> limits of the single process. > >Disagree. I want lightweight processes to have their own quantum >not limited (in total) to the parent process quantum. That would clearly kill the "lightweight" in "lightweight process"... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 4:41:49 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id CDEF114DFC for ; Tue, 2 Nov 1999 04:41:38 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA18602 for ; Tue, 2 Nov 1999 13:41:35 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA79442 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 13:41:35 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 7980814DFC for ; Tue, 2 Nov 1999 04:41:10 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt85.pcnet.net [206.105.29.159]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id HAA09441; Tue, 2 Nov 1999 07:39:49 -0500 (EST) Message-ID: <381EDBCE.FD7FBA68@vigrid.com> Date: Tue, 02 Nov 1999 07:40:46 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) References: <25550.941545442@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > > In message <381ED720.5A24A02B@vigrid.com>, "Daniel M. Eischen" writes: > > >> 6/ (contentious) multiple theads should be bound to within the resource > >> limits of the single process. > > > >Disagree. I want lightweight processes to have their own quantum > >not limited (in total) to the parent process quantum. > > That would clearly kill the "lightweight" in "lightweight process"... That doesn't mean they each have to have the same quantum as a non-MT process. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 4:45:39 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D9D7614DFC for ; Tue, 2 Nov 1999 04:45:28 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA18676 for ; Tue, 2 Nov 1999 13:45:26 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA79513 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 13:45:26 +0100 (MET) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id A641114DFC for ; Tue, 2 Nov 1999 04:45:03 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id NAA25678; Tue, 2 Nov 1999 13:44:49 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Daniel M. Eischen" Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) In-reply-to: Your message of "Tue, 02 Nov 1999 07:40:46 EST." <381EDBCE.FD7FBA68@vigrid.com> Date: Tue, 02 Nov 1999 13:44:48 +0100 Message-ID: <25676.941546688@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <381EDBCE.FD7FBA68@vigrid.com>, "Daniel M. Eischen" writes: >> >Disagree. I want lightweight processes to have their own quantum >> >not limited (in total) to the parent process quantum. >> >> That would clearly kill the "lightweight" in "lightweight process"... > >That doesn't mean they each have to have the same quantum as a non-MT >process. That has nothing to do with it. There is not much point in making a lightweight process facility if the resulting processes are not lightweight. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 5: 3:14 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A7E8014D26 for ; Tue, 2 Nov 1999 05:02:55 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id OAA18983 for ; Tue, 2 Nov 1999 14:02:54 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA79672 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 14:02:53 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id C7B4814D26 for ; Tue, 2 Nov 1999 05:02:31 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt85.pcnet.net [206.105.29.159]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id IAA12079; Tue, 2 Nov 1999 08:01:11 -0500 (EST) Message-ID: <381EE0D0.874F6198@vigrid.com> Date: Tue, 02 Nov 1999 08:02:08 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) References: <25676.941546688@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > > In message <381EDBCE.FD7FBA68@vigrid.com>, "Daniel M. Eischen" writes: > > >> >Disagree. I want lightweight processes to have their own quantum > >> >not limited (in total) to the parent process quantum. > >> > >> That would clearly kill the "lightweight" in "lightweight process"... > > > >That doesn't mean they each have to have the same quantum as a non-MT > >process. > > That has nothing to do with it. > > There is not much point in making a lightweight process facility > if the resulting processes are not lightweight. And quantum is _the_ attribute that makes them lightweight or non lightweight? They each share file descriptors, address space, etc. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 5: 8:39 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0BCD0153C9 for ; Tue, 2 Nov 1999 05:08:27 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id OAA19065 for ; Tue, 2 Nov 1999 14:08:26 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA79707 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 14:08:26 +0100 (MET) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (Postfix) with ESMTP id AFC15153A7 for ; Tue, 2 Nov 1999 05:07:40 -0800 (PST) (envelope-from michael.schuster@germany.sun.com) Received: from emuc05-home.Germany.Sun.COM ([129.157.51.10]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA03344 for ; Tue, 2 Nov 1999 05:07:31 -0800 (PST) Received: from germany.sun.com (hacker [129.157.167.97]) by emuc05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with ESMTP id OAA24489 for ; Tue, 2 Nov 1999 14:07:26 +0100 (MET) Message-ID: <381EE210.3997A52F@germany.sun.com> Date: Tue, 02 Nov 1999 14:07:28 +0100 From: Michael Schuster - TSC SunOS Germany Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) References: <25676.941546688@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > > In message <381EDBCE.FD7FBA68@vigrid.com>, "Daniel M. Eischen" writes: > > >> >Disagree. I want lightweight processes to have their own quantum > >> >not limited (in total) to the parent process quantum. > >> > >> That would clearly kill the "lightweight" in "lightweight process"... > > > >That doesn't mean they each have to have the same quantum as a non-MT > >process. > > That has nothing to do with it. > > There is not much point in making a lightweight process facility > if the resulting processes are not lightweight. I think we need a clarification here: In the sense that I've seen LWP used up to now (i.e. the Solaris sense, which I suggest we'll adhere to), an LWP is - figuratively speaking - the mapping between one or more user threads to _one_ kernel thread, i.e. a single scheduling entitity from the kernel's perspective, but not necessarily a single thread in the user's application's view. Every process has at least one LWP (and each LWP is associated with exactly one process). According to this definition, LWPs do have their own time quantum (since the kernel sees kthread quanta). I think you could loosely compare LWPs to "scheduler activations" in the Anderson paper (at least that's my understanding up to now). cheerio Michael PS: perhaps we need to define our terminology ... -- Michael Schuster / Michael.Schuster@germany.sun.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 5:23: 4 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2C751153C9 for ; Tue, 2 Nov 1999 05:22:52 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id OAA19342 for ; Tue, 2 Nov 1999 14:22:49 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA79835 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 14:22:49 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id C7682153C9 for ; Tue, 2 Nov 1999 05:22:22 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt85.pcnet.net [206.105.29.159]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id IAA14739; Tue, 2 Nov 1999 08:21:01 -0500 (EST) Message-ID: <381EE576.7C1AF9EE@vigrid.com> Date: Tue, 02 Nov 1999 08:21:58 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Michael Schuster - TSC SunOS Germany Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) References: <25676.941546688@critter.freebsd.dk> <381EE210.3997A52F@germany.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Michael Schuster - TSC SunOS Germany wrote: > In the sense that I've seen LWP used up to now (i.e. the Solaris sense, > which I suggest we'll adhere to), an LWP is - figuratively speaking - > the mapping between one or more user threads to _one_ kernel thread, > i.e. a single scheduling entitity from the kernel's perspective, but not > necessarily a single thread in the user's application's view. Every > process has at least one LWP (and each LWP is associated with exactly > one process). According to this definition, LWPs do have their own time > quantum (since the kernel sees kthread quanta). Yes. And I'm sure you're familiar with the various scheduling classes and the dispatch table (which shows the quantums) under Solaris. Note that if we want to support PTHREAD_SCOPE_SYSTEM, lighweight processes need to be able to contend for resources among all other threads in the system within the same scheduling domain. This, to me, implies their own quantum. And we can see that this is true for Solaris. > I think you could loosely compare LWPs to "scheduler activations" in the > Anderson paper (at least that's my understanding up to now). Agreed. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 5:51:54 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 18D0614A1F for ; Tue, 2 Nov 1999 05:51:44 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id OAA19935 for ; Tue, 2 Nov 1999 14:51:42 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA79952 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 14:51:42 +0100 (MET) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id CD05414A1F for ; Tue, 2 Nov 1999 05:51:11 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id OAA25853; Tue, 2 Nov 1999 14:50:42 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Daniel M. Eischen" Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) In-reply-to: Your message of "Tue, 02 Nov 1999 08:02:08 EST." <381EE0D0.874F6198@vigrid.com> Date: Tue, 02 Nov 1999 14:50:42 +0100 Message-ID: <25851.941550642@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <381EE0D0.874F6198@vigrid.com>, "Daniel M. Eischen" writes: >> There is not much point in making a lightweight process facility >> if the resulting processes are not lightweight. > >And quantum is _the_ attribute that makes them lightweight or non >lightweight? They each share file descriptors, address space, etc. Lack of overhead is what makes the lightweight. Keeping track of quanta, accounting permissions or anything else on a "per XXX" basis is "overhead" in this context. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 5:56:38 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 100E914BFF for ; Tue, 2 Nov 1999 05:56:30 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id OAA20054 for ; Tue, 2 Nov 1999 14:56:28 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA79987 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 14:56:28 +0100 (MET) Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id DADF414FBD for ; Tue, 2 Nov 1999 05:55:00 -0800 (PST) (envelope-from freebsd-arch@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id OAA30674 for arch@FreeBSD.org; Tue, 2 Nov 1999 14:25:07 +0100 (CET) (envelope-from freebsd-arch@scc.nl) Received: from GATEWAY by dwarf.hq.scc.nl with netnews for arch@FreeBSD.org (arch@FreeBSD.org) To: arch@freebsd.org Date: Tue, 02 Nov 1999 14:25:00 +0100 From: Marcel Moolenaar Message-ID: <381EE62C.A299A6B9@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: preview: Make world Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I've made my work-in-progress available at http://www.freebsd.org/~marcel/world.diff (184KB). Some hi(gh)lights: - No cleanup before building. - Non-root building. - Cross-building ready. Work to be done: - Build cross-compilation tools from sources. - Conditional tools building. From the /usr/src/Makefile comments: # Make command line options (enable): # # -DCOMPAT1X include FreeBSD 1.x compatibility # -DCOMPAT20 include FreeBSD 2.0.x compatibility # -DCOMPAT21 include FreeBSD 2.1.x compatibility # -DCOMPAT22 include FreeBSD 2.2.x compatibility # -DCOMPAT3X include FreeBSD 3.x compatibility # -DCSRG_LIBM use legacy libm # -DKERBEROS4 include KerberosIV # -DRELEASE release specialities (much of the above and more) # # Make command line options (disable): # # -DNOCRYPT do not build crypt versions # -DNOINFO do not make or install info files # -DNOPROFILE do not build profiled libraries # -DNOSECURE the secure subdir should not be built # # Make command line options (variables [with defaults]): # # TARGET_ARCH=[${MACHINE_ARCH}] # specifies the platform for which world is to # be built # KERNEL=[GENERIC] # specifies which kernel should be build as part # of a world # DESTDIR=[] # specifies where world is to be installed # # ======== # TODO # ======== # # Dependencies: # # - Handle makefile dependencies for makefiles that only include # bsd.subdir.mk. # - Handle the possible complex dependencies of makefiles caused by # the include directive. This can be handled by introducing a new # variable (MAKEFILES) to which each makefile appends its name. # bsd.dep.obj can iterate over these names and check timestamps. # - Handle the possible complex dependencies of build options. This # implies that a build must "remember" its options so that a re- # build can handle changes in these options. # # Cross building: # # - Double check make world without an existing /usr/include # - Double check make world without an existing /usr/lib # - Find out what needs to be done to build a cross-compiler # from the sources in the source tree. # # Tools building: # # - Design a generic and flexibly why to determine whether some tools # need to be build or not. For example: The tools subdir can hold # shell scripts that each handle a different tool (analogy with rc.d) # and basicly contains the checks and the make commands. # # Upgrading: # - Include checks to determine if bootblocks need to be installed # # Command line options: # # -DNOSUIDPERL # -DPERL_THREADED # -DNO_SENDMAIL # -DNO_CVS # -DNOMANCOMPRESS # # PRINTERDEVICE= # BOOTWAIT= # BOOT_COMCONSOLE_PORT= # BOOT_COMCONSOLE_SPEED= # TOP_TABLE_SIZE= # DEBUG_FLAGS= # # Miscellaneous: # # - Don't forget release building. # FYI, -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 6:11:17 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0B6F014BF5 for ; Tue, 2 Nov 1999 06:11:07 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id PAA20402 for ; Tue, 2 Nov 1999 15:11:06 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA80072 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 15:11:05 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id D545C14EAF for ; Tue, 2 Nov 1999 06:09:41 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt11.pcnet.net [206.105.29.85]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id JAA20713; Tue, 2 Nov 1999 09:08:09 -0500 (EST) Message-ID: <381EF084.C9292297@vigrid.com> Date: Tue, 02 Nov 1999 09:09:08 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) References: <25851.941550642@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > > In message <381EE0D0.874F6198@vigrid.com>, "Daniel M. Eischen" writes: > > >> There is not much point in making a lightweight process facility > >> if the resulting processes are not lightweight. > > > >And quantum is _the_ attribute that makes them lightweight or non > >lightweight? They each share file descriptors, address space, etc. > > Lack of overhead is what makes the lightweight. > > Keeping track of quanta, accounting permissions or anything else > on a "per XXX" basis is "overhead" in this context. I'll make an assumption that a lightweight process is just going to be another proc. A proc already contains scheduling attributes and it seems _extra_ work to make another dereference to get to the parents proc scheduling attributes. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 6:16: 6 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0E06E14EAF for ; Tue, 2 Nov 1999 06:15:55 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id PAA20494 for ; Tue, 2 Nov 1999 15:15:54 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA80098 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 15:15:53 +0100 (MET) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 022AD14EAF for ; Tue, 2 Nov 1999 06:15:29 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id PAA26001; Tue, 2 Nov 1999 15:15:10 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Daniel M. Eischen" Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) In-reply-to: Your message of "Tue, 02 Nov 1999 09:09:08 EST." <381EF084.C9292297@vigrid.com> Date: Tue, 02 Nov 1999 15:15:10 +0100 Message-ID: <25999.941552110@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <381EF084.C9292297@vigrid.com>, "Daniel M. Eischen" writes: >Poul-Henning Kamp wrote: >> >> In message <381EE0D0.874F6198@vigrid.com>, "Daniel M. Eischen" writes: >> >> >> There is not much point in making a lightweight process facility >> >> if the resulting processes are not lightweight. >> > >> >And quantum is _the_ attribute that makes them lightweight or non >> >lightweight? They each share file descriptors, address space, etc. >> >> Lack of overhead is what makes the lightweight. >> >> Keeping track of quanta, accounting permissions or anything else >> on a "per XXX" basis is "overhead" in this context. > >I'll make an assumption that a lightweight process is just going >to be another proc. A proc already contains scheduling attributes >and it seems _extra_ work to make another dereference to get to >the parents proc scheduling attributes. Think "context switch" -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 6:32:36 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 5324A15139 for ; Tue, 2 Nov 1999 06:32:27 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id PAA20849 for ; Tue, 2 Nov 1999 15:32:22 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA80166 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 15:32:21 +0100 (MET) Received: from test.tar.com (test.tar.com [204.95.187.4]) by hub.freebsd.org (Postfix) with ESMTP id D9E7B153E3 for ; Tue, 2 Nov 1999 06:28:05 -0800 (PST) (envelope-from dick@test.tar.com) Received: (from dick@localhost) by test.tar.com (8.9.3/8.9.3) id IAA28100; Tue, 2 Nov 1999 08:27:59 -0600 (CST) (envelope-from dick) Date: Tue, 2 Nov 1999 08:27:59 -0600 From: "Richard Seaman, Jr." To: Julian Elischer Cc: freebsd-arch@freebsd.org, rcarter@pinyon.org Subject: Re: Threads models and FreeBSD. (Next Step) Message-ID: <19991102082758.D5715@tar.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Nov 02, 1999 at 12:59:28AM -0800, Julian Elischer wrote: [.....] > We have 4 starters at this point. Note, they MAY NOT BE mutually > exclusive! > > 1/ The scheme we've been working towards for a while due to lack of > suggested alternatives.. rfork based processes sharing resources. > This is very similar to the Linuxthreads implementation. one kernel > schedulable entity (light process) per thread. > 1A/ actually use the linuxthread code.. FYI Russell Carter has updated the linuxthread port, and has indicated to me an interest in taking over this project, since I haven't had time to work on it lately. Be aware that the linuxthread port uses an older version of linuxthreads. While newer versions may not be that hard to bring over, it appears that the new linuxthreads will start to rely on features of the linux kernel that will have to be implemented in the FreeBSD kernel (eg. threads sharing the parent pid). This may well be necessary anyway for the linux emulator, but in general using linuxthreads will put you in the position of having to implement linux kernel features that the linuxthreads library needs. I have some thoughts on using the existing uthread to move to m/n user/kernel threads that I will try to put down later. -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 6:42:18 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 368B4153E3 for ; Tue, 2 Nov 1999 06:42:05 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id PAA21491 for ; Tue, 2 Nov 1999 15:42:03 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA80223 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 15:42:03 +0100 (MET) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 04CB0153FC for ; Tue, 2 Nov 1999 06:41:21 -0800 (PST) (envelope-from rcarter@chomsky.Pinyon.ORG) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id HAA10640; Tue, 2 Nov 1999 07:39:05 -0700 (MST) Received: from ip-26-042.prc.primenet.com(206.165.26.42), claiming to be "chomsky.pinyon.org" via SMTP by smtp01.primenet.com, id smtpdAAAU0aWRu; Tue Nov 2 07:38:56 1999 Received: from chomsky.Pinyon.ORG (localhost [127.0.0.1]) by chomsky.pinyon.org (Postfix) with ESMTP id 5D0F23B; Tue, 2 Nov 1999 07:38:19 -0700 (MST) X-Mailer: exmh version 2.1.0 09/18/1999 To: Poul-Henning Kamp Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) In-Reply-To: Message from Poul-Henning Kamp of "Tue, 02 Nov 1999 13:44:48 +0100." <25676.941546688@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Nov 1999 07:38:19 -0700 From: "Russell L. Carter" Message-Id: <19991102143819.5D0F23B@chomsky.pinyon.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG %In message <381EDBCE.FD7FBA68@vigrid.com>, "Daniel M. Eischen" writes: % %>> >Disagree. I want lightweight processes to have their own quantum %>> >not limited (in total) to the parent process quantum. %>> %>> That would clearly kill the "lightweight" in "lightweight process"... %> %>That doesn't mean they each have to have the same quantum as a non-MT %>process. % %That has nothing to do with it. % %There is not much point in making a lightweight process facility %if the resulting processes are not lightweight. Then the application developer should choose libc_r threads. There isn't much point to doing this effort if the pthread_*sched* functions don't actually mean much in the global context. People building large scale distributed objects that are also high performance require fine grained schedulability of individual threads. I can provide references that demonstrate how low level thread scheduling architecture affect high level services. Solaris, HP, MVS, and Linux support this to varying degrees now. The RT-OSs more or less do, though some fail in surprising ways. Linux is surprisingly good. Put another way, cramming a process's threads into a single scheduling quanta significantly diminishes the suitability of FreeBSD as a platform for building high performance and/or RT CORBA apps. Regards, Russell %-- %Poul-Henning Kamp FreeBSD coreteam member %phk@FreeBSD.ORG "Real hackers run -current on their laptop." %FreeBSD -- It will take a long time before progress goes too far! % % % % %To Unsubscribe: send mail to majordomo@FreeBSD.org %with "unsubscribe freebsd-arch" in the body of the message % To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 6:45:21 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 934E515139 for ; Tue, 2 Nov 1999 06:45:15 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id PAA21553 for ; Tue, 2 Nov 1999 15:45:14 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA80256 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 15:45:14 +0100 (MET) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id A2B6515433 for ; Tue, 2 Nov 1999 06:43:48 -0800 (PST) (envelope-from rcarter@chomsky.Pinyon.ORG) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id HAA01308; Tue, 2 Nov 1999 07:43:45 -0700 (MST) Received: from ip-26-042.prc.primenet.com(206.165.26.42), claiming to be "chomsky.pinyon.org" via SMTP by smtp02.primenet.com, id smtpd001271; Tue Nov 2 07:43:37 1999 Received: from chomsky.Pinyon.ORG (localhost [127.0.0.1]) by chomsky.pinyon.org (Postfix) with ESMTP id 0AFD67B; Tue, 2 Nov 1999 07:43:36 -0700 (MST) X-Mailer: exmh version 2.1.0 09/18/1999 To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) In-Reply-To: Message from Julian Elischer of "Tue, 02 Nov 1999 00:59:28 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Nov 1999 07:43:36 -0700 From: "Russell L. Carter" Message-Id: <19991102144336.0AFD67B@chomsky.pinyon.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG % %Here is an updated version of the rather simplistic requirements for a %threads model for freeBSD. % %It is notable that we already support Linux kernel threads on FreeBSD %better than we support a native threads model. This is because we support %the 'clone' system call through our rfork() code, and that is their basis %for threading. As is common for this group of people, we have not adopted %the Linux approach because it is considered to be 'too simplistic', %assigning a separate kernel schedulable process to run each thread. % %Having said that, Amancio Hasty at one stage wrote a set of threading %primitives to allow Kafe to run on FreeBSD using this scheme of threading, %and Richard Seaman has a port of the Linuxthreads code to freeBSD at his %website, http://lt.tar.com/ . This represents a useful piece of work and Richard seems to have been diverted in recent months, I have a copy of his port made freestanding and building against this weeks -current sitting at http://www.Pinyon.ORG/ace/lthreads-991029.tar.gz This unfortunately does not work on SMP due to some problem with signals, previously it worked fine on some heavy duty applications. It still works fine on -current single processor. Russell To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 7:51: 7 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 5884D1504E for ; Tue, 2 Nov 1999 07:50:54 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id QAA22653 for ; Tue, 2 Nov 1999 16:50:51 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA80642 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 16:50:51 +0100 (MET) Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 657FB1504E for ; Tue, 2 Nov 1999 07:50:32 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id KAA10625 for ; Tue, 2 Nov 1999 10:45:55 -0500 (EST) Reply-To: Randell Jesup To: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) References: <19991102143819.5D0F23B@chomsky.pinyon.org> From: Randell Jesup Date: 02 Nov 1999 11:47:02 +0000 In-Reply-To: "Russell L. Carter"'s message of "Tue, 02 Nov 1999 07:38:19 -0700" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Russell L. Carter" writes: >%>> >Disagree. I want lightweight processes to have their own quantum >%>> >not limited (in total) to the parent process quantum. >%There is not much point in making a lightweight process facility >%if the resulting processes are not lightweight. Perhaps - but what defines 'lightweight'? I've always thought that processes that share resources/memory were 'lightweight'. Also, I think the proposal was that you could have 1 to N LWP's for a process with N threads. Whatever you want to call them, there certainly seems to be a use for 'something' between user-scheduled threads and processes. >There isn't much point to doing this effort if the >pthread_*sched* functions don't actually mean much in the >global context. This is a very good point. >People building large scale distributed objects that >are also high performance require fine grained schedulability >of individual threads. I can provide references that demonstrate >how low level thread scheduling architecture >affect high level services. While I wouldn't want you to go far out of your way, a reference or two (or summary thereof) might help people. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 8:22: 3 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 7BE7815075 for ; Tue, 2 Nov 1999 08:21:50 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id RAA23090 for ; Tue, 2 Nov 1999 17:21:49 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA80793 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 17:21:47 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id E6CDE1502C for ; Tue, 2 Nov 1999 08:19:23 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id IAA86395; Tue, 2 Nov 1999 08:19:20 -0800 (PST) Date: Tue, 2 Nov 1999 08:19:19 -0800 (PST) From: Julian Elischer To: "Daniel M. Eischen" Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) In-Reply-To: <381ED720.5A24A02B@vigrid.com> 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 Tue, 2 Nov 1999, Daniel M. Eischen wrote: > Julian Elischer wrote: > > > > Here is an updated version of the rather simplistic requirements for a > > threads model for freeBSD. > [...] > > > > 1/ Multiple independent 'threads of control' within a single process > > at user level. The most basic quality of threads. > > > > 2/ Ability to simultaneously schedule M threads over N Processors, > > and have min(M,N) threads simultaneously executing. > > Shouldn't this be M threads over N [lightweight] Processes? well, not until we decide that we are going to HAVE LWPs. :-) this is teh really highest level requirement. > > > 6/ (contentious) multiple theads should be bound to within the resource > > limits of the single process. > > Disagree. I want lightweight processes to have their own quantum > not limited (in total) to the parent process quantum. Most people disagree with you on this one, so if you want what you describe, you will have to thik of a way of decribing it as an optional characteristic. We discussed this and the overwhelming majority decided that a threaded program has no real scheduling advantage over a non threaded program, oth that what it get's by teh nature of blockin gless and being on multiple CPUs. Having said that, it is possible that you want your threaded proggram to hog the system (the sysadmin may disagree, in which case you must still be bound by your process limits). Should this be the case, you should be able to specify some optional (non default) characteristic that allows this.. If you can thinkk of a good way of describing this, we can include it.. (but it can't be the default behaviour as far as I can see.) > > > ------------- > > Meta-goals > > ----------- > > We should keep our eyes on: > > *) scalability > > *) performance > > *) ability to support features required by standards based threads. > > *) ability to support features of those therad packages we select as > > needed. > > How about [from the "scheduler activations" paper] Flexibility? * define 'flexibility' ? :-) I think the 4th point covers what we need in that regard? > > > > > refs: > > http://www.freebsd.org/~deischen/p95-anderson.pdf > > http://www.freebsd.org/cgi/getmsg.cgi?fetch=25000+30231+/usr/local/www/db/text/1 > > 999/freebsd-current/19990321.freebsd-current > > http://lt.tar.com/ > > Do you want other references? I know there are several available papers on > Solaris multi-threading. There are also papers on locking mechanisms. > yes. references are good. > Dan Eischen > eischen@vigrid.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 9:14:46 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 1F77B14C95 for ; Tue, 2 Nov 1999 09:14:39 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA23706 for ; Tue, 2 Nov 1999 18:14:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA81015 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 18:14:36 +0100 (MET) Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id 6FA9414FBC for ; Tue, 2 Nov 1999 08:58:08 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 28553 invoked by uid 500); 2 Nov 1999 16:47:57 -0000 Date: Tue, 2 Nov 1999 08:47:57 -0800 From: Jason Evans To: "Daniel M. Eischen" Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) Message-ID: <19991102084756.Z729@sturm.canonware.com> References: <381ED720.5A24A02B@vigrid.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2us In-Reply-To: <381ED720.5A24A02B@vigrid.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Nov 02, 1999 at 07:20:48AM -0500, Daniel M. Eischen wrote: > Julian Elischer wrote: > > > > Here is an updated version of the rather simplistic requirements for a > > threads model for freeBSD. > [...] > > > > 1/ Multiple independent 'threads of control' within a single process > > at user level. The most basic quality of threads. > > > > 2/ Ability to simultaneously schedule M threads over N Processors, > > and have min(M,N) threads simultaneously executing. > > Shouldn't this be M threads over N [lightweight] Processes? The ultimate goal of M:N thread scheduling (thread:LWP), as in OSes such as Solaris, is to allow simultaneous execution of threads on (ideally) all the processors in a system. That is, the goal should be M:P scheduling, (thread:processor). As such, Solaris's LWP approach does a statistically acceptable job of using the available processors, but from a pragmatic point of view, it's a very complex (and high overhead) solution to the problem. In my opinion, Solaris's solution is not ideal, and we should strive to do better. > > 6/ (contentious) multiple theads should be bound to within the resource > > limits of the single process. > > Disagree. I want lightweight processes to have their own quantum > not limited (in total) to the parent process quantum. I disagree with your disagreement. =) First, as explained above, I don't think we should be talking in terms of LWPs. Second, from a view external to the kernel, to treat a single-threaded process as a second class citizen IMO breaks the notion of process scheduling. Of course, depending on the implementation we go with, process accounting may be difficult to do "correctly", so some compromise may be necessary. Jason Jason Evans http://www.canonware.com/~jasone Home phone: (650) 856-8204 Work phone: (415) 808-8742 "I once knew a happy medium. Her name was Zohar." - James Foster To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 9:15:19 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C926814C03 for ; Tue, 2 Nov 1999 09:15:13 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA23733 for ; Tue, 2 Nov 1999 18:15:12 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA81040 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 18:15:11 +0100 (MET) Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 6FB0014C03 for ; Tue, 2 Nov 1999 09:05:07 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id JAA27754 for ; Tue, 2 Nov 1999 09:05:06 -0800 (PST) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id JAA28212; Tue, 2 Nov 1999 09:05:05 -0800 Received: from softweyr.com (dyn7.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA11985; Tue, 2 Nov 99 09:05:04 PST Message-Id: <381F19C0.577FFA0D@softweyr.com> Date: Tue, 02 Nov 1999 10:05:04 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Extended partitions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I lent my 3.3 CDROMs to a friend who is a dedicated linux-head last night. He was disappointed to find that FreeBSD doesn't support installing onto a logical drive on an extended partition. In response, he offered to write support for such for FreeBSD. I'm willing to shepherd his work, collect reviews, commit when ready, and such. Is this something we (collective "we", not royal "we") are interested in? In case you're wondering about Chris' ability to deliver, he used to work on filesystem code at some large network server company in Utah, and is pretty clueful. He's even willing to release the code under BSD license terms, so we wouldn't have to worry about silly encumberances. Yes? No? Maybe? If there is sufficient interest, I'll explain to him how to CVSup and get him rolling on it ASAP. This would be nice to have for 4.0 release. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 9:18:23 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C7B8414A05 for ; Tue, 2 Nov 1999 09:18:12 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA23778 for ; Tue, 2 Nov 1999 18:18:11 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA81104 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 18:18:11 +0100 (MET) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 6A82514A31 for ; Tue, 2 Nov 1999 09:17:55 -0800 (PST) (envelope-from rcarter@chomsky.Pinyon.ORG) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id KAA01566; Tue, 2 Nov 1999 10:17:40 -0700 (MST) Received: from ip-83-168.prc.primenet.com(207.218.83.168), claiming to be "chomsky.pinyon.org" via SMTP by smtp01.primenet.com, id smtpdAAAkDaq3c; Tue Nov 2 10:17:33 1999 Received: from chomsky.Pinyon.ORG (localhost [127.0.0.1]) by chomsky.pinyon.org (Postfix) with ESMTP id BAE8D58; Tue, 2 Nov 1999 10:16:50 -0700 (MST) X-Mailer: exmh version 2.1.0 09/18/1999 To: Julian Elischer Cc: "Daniel M. Eischen" , freebsd-arch@freebsd.org, rcarter@pinyon.org Subject: Re: Threads models and FreeBSD. (Next Step) In-Reply-To: Message from Julian Elischer of "Tue, 02 Nov 1999 08:19:19 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Nov 1999 10:16:50 -0700 From: "Russell L. Carter" Message-Id: <19991102171650.BAE8D58@chomsky.pinyon.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry for the long inclusion, but... % % %On Tue, 2 Nov 1999, Daniel M. Eischen wrote: % %> Julian Elischer wrote: %> > %> > Here is an updated version of the rather simplistic requirements for a %> > threads model for freeBSD. %> [...] %> > %> > 1/ Multiple independent 'threads of control' within a single process %> > at user level. The most basic quality of threads. %> > %> > 2/ Ability to simultaneously schedule M threads over N Processors, %> > and have min(M,N) threads simultaneously executing. %> %> Shouldn't this be M threads over N [lightweight] Processes? %well, not until we decide that we are going to HAVE LWPs. :-) %this is teh really highest level requirement. %> %> > 6/ (contentious) multiple theads should be bound to within the resource %> > limits of the single process. %> %> Disagree. I want lightweight processes to have their own quantum %> not limited (in total) to the parent process quantum. % %Most people disagree with you on this one, so if you want what you %describe, you will have to thik of a way of decribing it as an optional %characteristic. We discussed this and the overwhelming majority decided %that a threaded program has no real scheduling advantage over a non %threaded program, oth that what it get's by teh nature of blockin gless %and being on multiple CPUs. Having said that, it is possible that you want %your threaded proggram to hog the system (the sysadmin may disagree, in %which case you must still be bound by your process limits). Should this be %the case, you should be able to specify some optional (non %default) characteristic that allows this.. If you can thinkk of a good way %of describing this, we can include it.. (but it can't be the default %behaviour as far as I can see.) % I don't see my responses on the list, is it for committers only? If so, this will be my last contrib. I agree with Daniel. Randell Jesup writes: % While I wouldn't want you to go far out of your way, a reference %or two (or summary thereof) might help people. This one details how (multithreaded) distributed objects can be implemented so that QoS requirements can be met, it's pretty much the definitive paper so far on how these things are done. Included is a detailed analysis of threading models. However, it's 55 pages long. http://www.cs.wustl.edu/~schmidt/RT-ORB.ps.gz This one focuses in on thread QoS performance for a variety OS's, including NT, Linux, Solaris, VxWorks, and Lynx, with an implementation of the designs in the above paper: http://www.cs.wustl.edu/~schmidt/RT-OS.ps.gz Here's a paper which extracts out the threading issues from RT-ORB.ps and discusses it in 8 pages: http://www.cs.wustl.edu/~schmidt/CACM-arch.ps.gz To summarize, I have clients that are very large companies that have settled on the architecture described in these papers. Most of the new development projects for the U.S. DoD that I am familiar with incorporate some aspect of this technology in their architecture. Apparently, some telcos and financial systems are adopting as well. High performance/RT distributed objects were a fiasco until the thread capabilities began to mature, but now it is pretty well understood how to build these things given a complete thread implementation such as described in Kleiman, Shah, and Smaalders. From their book, I quote (p207-208): "There are some cases in which it is not desirable for a thread to be scheduled purely local to a process. In particular, threads that must be scheduled on a realtime basis must be prioritized and scheduled with respect to all the other threads in the system; in other words, they must have system-wide contention scope". Though I'm not sure what the problem is here, pthread_attr_setscope is defined to take either PTHREAD_SCOPE_PROCESS or PTHREAD_SCOPE_SYSTEM. Just don't give PTHREAD_SCOPE_SYSTEM capability to unpriviledged processes. Russell % % %> %> > ------------- %> > Meta-goals %> > ----------- %> > We should keep our eyes on: %> > *) scalability %> > *) performance %> > *) ability to support features required by standards based threads. %> > *) ability to support features of those therad packages we select as %> > needed. %> %> How about [from the "scheduler activations" paper] Flexibility? % %* define 'flexibility' ? :-) I think the 4th point covers what we %need in that regard? % %> %> > %> > refs: %> > http://www.freebsd.org/~deischen/p95-anderson.pdf %> > http://www.freebsd.org/cgi/getmsg.cgi?fetch=25000+30231+/usr/local/www/db/text/1 %> > 999/freebsd-current/19990321.freebsd-current %> > http://lt.tar.com/ %> %> Do you want other references? I know there are several available papers on %> Solaris multi-threading. There are also papers on locking mechanisms. %> %yes. references are good. % % %> Dan Eischen %> eischen@vigrid.com %> % % % % % %To Unsubscribe: send mail to majordomo@FreeBSD.org %with "unsubscribe freebsd-arch" in the body of the message % To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 9:38:35 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id BA69314BD2 for ; Tue, 2 Nov 1999 09:38:29 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA23936 for ; Tue, 2 Nov 1999 18:38:28 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA81274 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 18:38:28 +0100 (MET) Received: from io.yi.org (24.66.174.118.bc.wave.home.com [24.66.174.118]) by hub.freebsd.org (Postfix) with ESMTP id 0440114A09 for ; Tue, 2 Nov 1999 09:37:35 -0800 (PST) (envelope-from jake@checker.org) Received: from io.yi.org (localhost [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id 9E34E1FCD; Tue, 2 Nov 1999 09:37:36 -0800 (PST) X-Mailer: exmh version 2.1.0 09/18/1999 To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) In-reply-to: Your message of "Tue, 02 Nov 1999 08:19:19 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Nov 1999 09:37:36 -0800 From: Jake Burkholder Message-Id: <19991102173736.9E34E1FCD@io.yi.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Most people disagree with you on this one, so if you want what you > describe, you will have to thik of a way of decribing it as an optional > characteristic. We discussed this and the overwhelming majority decided > that a threaded program has no real scheduling advantage over a non > threaded program, oth that what it get's by teh nature of blockin gless > and being on multiple CPUs. Having said that, it is possible that you want > your threaded proggram to hog the system (the sysadmin may disagree, in > which case you must still be bound by your process limits). Should this be > the case, you should be able to specify some optional (non > default) characteristic that allows this.. If you can thinkk of a good way > of describing this, we can include it.. (but it can't be the default > behaviour as far as I can see.) > I agree with Daniel. I thought the scheduler activations paper had an elegant solution to this. Multi-threaded processes are rewarded for returning scedulable entities (struct proc) back to the system; and possibly penlaized for not doing so. How about each schedulable entity recieves a quantum of number of cpus / number of entities in this process? In a multi threaded process with 2 schedulable entities on a uniprocessor system, each entity recieves a quantum of 1/2. In a multi threaded process with 2 schedulable entities on a dual processor system, each entity recieves a quantum of 1. In a multi threaded process with 3 schedulable entities on a dual processor system, each entity recieves a quantum of 2/3. In essence each multi-threaded process recieves quantum equal to number of cpus in the system, and this is then divided among its schedulable entities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 9:39:11 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 55F4714BD2 for ; Tue, 2 Nov 1999 09:39:03 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA23951 for ; Tue, 2 Nov 1999 18:38:58 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA81296 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 18:38:57 +0100 (MET) Received: from mta2.rcsntx.swbell.net (mta2.rcsntx.swbell.net [151.164.30.26]) by hub.freebsd.org (Postfix) with ESMTP id 13EB414DB2 for ; Tue, 2 Nov 1999 09:38:31 -0800 (PST) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org ([216.62.157.60]) by mta2.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with ESMTP id <0FKK00CDEZMAZ7@mta2.rcsntx.swbell.net> for freebsd-arch@FreeBSD.ORG; Tue, 2 Nov 1999 11:37:22 -0600 (CST) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id LAA06531; Tue, 02 Nov 1999 11:38:10 -0600 (CST envelope-from chris) X-URL: http://www.FreeBSD.org/~chris/ Date: Tue, 02 Nov 1999 11:38:10 -0600 From: Chris Costello Subject: Re: Extended partitions In-reply-to: <381F19C0.577FFA0D@softweyr.com> To: Wes Peters Cc: freebsd-arch@freebsd.org Reply-To: chris@calldei.com Message-id: <19991102113810.U602@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i X-Operating-System: FreeBSD 4.0-CURRENT (i386) References: <381F19C0.577FFA0D@softweyr.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Nov 02, 1999, Wes Peters wrote: > Yes? No? Maybe? If there is sufficient interest, I'll explain to him how > to CVSup and get him rolling on it ASAP. This would be nice to have for > 4.0 release. Absolutely! People wanting to try it out before they switch will love this. -- |Chris Costello |Every program in development at MIT expands until it can read mail. `------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 9:45:10 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 7564014C4A for ; Tue, 2 Nov 1999 09:45:01 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA24036 for ; Tue, 2 Nov 1999 18:44:59 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA81341 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 18:44:59 +0100 (MET) Received: from plunger.gdeb.com (plunger.gdeb.com [153.11.11.3]) by hub.freebsd.org (Postfix) with ESMTP id EC63E14BD2 for ; Tue, 2 Nov 1999 09:43:51 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from orion.caen.gdeb.com ([153.11.109.11]) by plunger.gdeb.com with ESMTP id MAA01561; Tue, 2 Nov 1999 12:17:21 -0500 (EST) Received: from vigrid.com (clcrtr [153.11.109.129]) by orion.caen.gdeb.com (8.9.3/8.9.3) with ESMTP id MAA44897; Tue, 2 Nov 1999 12:42:01 -0500 (EST) (envelope-from eischen@vigrid.com) Message-ID: <381F2268.AAF0498C@vigrid.com> Date: Tue, 02 Nov 1999 12:42:00 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.51 [en] (X11; U; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > On Tue, 2 Nov 1999, Daniel M. Eischen wrote: > > > Julian Elischer wrote: > > > 6/ (contentious) multiple theads should be bound to within the resource > > > limits of the single process. > > > > Disagree. I want lightweight processes to have their own quantum > > not limited (in total) to the parent process quantum. > > Most people disagree with you on this one, so if you want what you > describe, you will have to thik of a way of decribing it as an optional > characteristic. We discussed this and the overwhelming majority decided > that a threaded program has no real scheduling advantage over a non > threaded program, oth that what it get's by teh nature of blockin gless > and being on multiple CPUs. Having said that, it is possible that you want > your threaded proggram to hog the system (the sysadmin may disagree, in > which case you must still be bound by your process limits). Should this be > the case, you should be able to specify some optional (non > default) characteristic that allows this.. If you can thinkk of a good way > of describing this, we can include it.. (but it can't be the default > behaviour as far as I can see.) An application can fork/rfork just as well as create a new thread with PTHREAD_SCOPE_SYSTEM. I really don't see what prohibiting LWPs from having their own quantum is buying us. I want to fully implement POSIX POSIX pthreads. I want to be able to create a thread with contention scope PTHREAD_SCOPE_SYSTEM and have it compete with all other system scope threads in the system for resources. I want what other OSs already have (well, at least Solaris). Maybe we should spend some more time looking at this from the other direction - what do we need from the kernel to fully implement POSIX and SSv2 pthreads? Let's not choose a threading model that prevents or makes it very difficult to implement the standard pthread interfaces. That said, if you want to prohibit PTHREAD_SCOPE_SYSTEM threads from being created without proper priveleges, I can deal with that, but I don't think it's necessary. > > > > > ------------- > > > Meta-goals > > > ----------- > > > We should keep our eyes on: > > > *) scalability > > > *) performance > > > *) ability to support features required by standards based threads. > > > *) ability to support features of those therad packages we select as > > > needed. > > > > How about [from the "scheduler activations" paper] Flexibility? > > * define 'flexibility' ? :-) I think the 4th point covers what we > need in that regard? OK, I guess 'flexibility' fits in there. > > Do you want other references? I know there are several available papers on > > Solaris multi-threading. There are also papers on locking mechanisms. > > > yes. references are good. OK, I'll dig some up. One would be the Valhalia book "UNIX Internals: The New Frontier" which does describe various threading models. It also mentions the scheduler activations paper. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 9:55:46 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 76EF414D37 for ; Tue, 2 Nov 1999 09:55:40 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA24177 for ; Tue, 2 Nov 1999 18:55:38 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA81444 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 18:55:38 +0100 (MET) Received: from plunger.gdeb.com (plunger.gdeb.com [153.11.11.3]) by hub.freebsd.org (Postfix) with ESMTP id CCADB14CD3 for ; Tue, 2 Nov 1999 09:55:06 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from orion.caen.gdeb.com ([153.11.109.11]) by plunger.gdeb.com with ESMTP id MAA01957; Tue, 2 Nov 1999 12:28:37 -0500 (EST) Received: from vigrid.com (clcrtr [153.11.109.129]) by orion.caen.gdeb.com (8.9.3/8.9.3) with ESMTP id MAA44908; Tue, 2 Nov 1999 12:53:22 -0500 (EST) (envelope-from eischen@vigrid.com) Message-ID: <381F2512.885AC9F@vigrid.com> Date: Tue, 02 Nov 1999 12:53:22 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.51 [en] (X11; U; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jason Evans Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) References: <381ED720.5A24A02B@vigrid.com> <19991102084756.Z729@sturm.canonware.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jason Evans wrote: > > The ultimate goal of M:N thread scheduling (thread:LWP), as in OSes such as > Solaris, is to allow simultaneous execution of threads on (ideally) all the > processors in a system. That is, the goal should be M:P scheduling, > (thread:processor). As such, Solaris's LWP approach does a statistically > acceptable job of using the available processors, but from a pragmatic > point of view, it's a very complex (and high overhead) solution to the > problem. In my opinion, Solaris's solution is not ideal, and we should > strive to do better. We currently have only user based threads. A Solaris-like implementation would be much better than what we have now. Perhaps we really do need some definitions. We need more than one "schedulable entity" to be able to run simulataneously on multiple processor. > > > 6/ (contentious) multiple theads should be bound to within the resource > > > limits of the single process. > > > > Disagree. I want lightweight processes to have their own quantum > > not limited (in total) to the parent process quantum. > > I disagree with your disagreement. =) First, as explained above, I don't > think we should be talking in terms of LWPs. I needed _some_ term to mean "schedulable entity", within which a PTHREAD_SCOPE_SYSTEM thread could run. > Second, from a view external > to the kernel, to treat a single-threaded process as a second class citizen > IMO breaks the notion of process scheduling. Of course, depending on the > implementation we go with, process accounting may be difficult to do > "correctly", so some compromise may be necessary. And what about an application that forks/rforks? It becomes supreme being and that's OK ;-) Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 11:30:19 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0DB5615067 for ; Tue, 2 Nov 1999 11:30:13 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA25027 for ; Tue, 2 Nov 1999 20:30:11 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA81858 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 20:30:11 +0100 (MET) Received: by hub.freebsd.org (Postfix, from userid 758) id 44F08151A6; Tue, 2 Nov 1999 11:29:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 9AFD21CD760 for ; Tue, 2 Nov 1999 11:29:24 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Tue, 2 Nov 1999 11:29:24 -0800 (PST) From: Kris Kennaway To: arch@freebsd.org Subject: Thread references 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 Below are a bunch of papers I was able to dig up last night which reference the threading models of other OSes, as well as some general papers. The Solaris implementation papers from Usenix are especially interesting - I strongly suggest everyone reads at least those, since the Solaris implementation is probably the "strongest" existing model. Something I'm unclear on though is whether that information is protected by patents or whether by publishing in the usenix proceedings it becomes an open source, and so whether we're allowed to refer to it in our own design. Kris ---- Cthulhu for President! For when you're tired of choosing the _lesser_ of two evils.. ---------- Forwarded message ---------- Date: Mon, 1 Nov 1999 19:10:57 -0800 (PST) From: Kris Kennaway To: Chuck Robey Subject: Re: Threads models and FreeBSD. On Sun, 31 Oct 1999, Chuck Robey wrote: > Kris, if you know any other references, especially to how other OSs do > threads, I'd really appreciate any pointers at all. I'm reading your last > one now. Well, credit goes to Dan Eischen for finding that one. Other possibly useful papers I've been able to dig up or find reference to are: CHORUS: ftp://ftp.chorus.fr/pub/chorus-reports/ In particular.. ftp://ftp.chorus.fr/pub/chorus-reports/CS-TR-91-7.ps.Z ftp://ftp.chorus.fr/pub/chorus-reports/CS-TR-89-37.ps.Z MACH: Some of the interesting-looking ones: ftp://ftp.cs.cmu.edu/project/mach/doc/published/Rcs.ps ftp://ftp.cs.cmu.edu/project/mach/doc/unpublished/sched.concur.ps ftp://ftp.cs.cmu.edu/project/mach/doc/unpublished/threads.ps ftp://ftp.cs.cmu.edu/project/mach/doc/published/cont_threads.ps ftp://ftp.cs.cmu.edu/project/mach/doc/published/cmultithread.ps DEC: http://www.crl.research.digital.com/publications/techreports/techreports.html http://www.digital.com/info/DTJF03/DTJF03SC.TXT ftp://ftp.crl.research.digital.com/pub/dec/Alpha/alpha-osf1-call-std-v1_3.ps I can't seem to find them now, but there were a bunch of old DEC tech reports from the mid to late 80s describing the Firefly system. Solaris: http://www.sun.com/smcc/solaris-migration/docs/courses/threadsHTML/contents.html http://suncom.bilkent.edu.tr/workshop/sig/threads/ in particular http://suncom.bilkent.edu.tr/workshop/sig/threads/usenix.html Wow, I've surprised myself how much cool stuff I've been able to dig up! There are undoubtledly others I haven't turned up yet (CS departments at the major universities are good places to look) - I'd be interested to know of any others you find. Kris ---- Cthulhu for President! For when you're tired of choosing the _lesser_ of two evils.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 12:19:44 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A46541525D for ; Tue, 2 Nov 1999 12:19:39 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA25465 for ; Tue, 2 Nov 1999 21:19:38 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA82091 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 21:19:36 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 5E2DB1525D; Tue, 2 Nov 1999 12:19:22 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id PAA16179; Tue, 2 Nov 1999 15:18:07 -0500 (EST) Date: Tue, 2 Nov 1999 15:18:07 -0500 (EST) From: Daniel Eischen To: Kris Kennaway Cc: arch@freebsd.org Subject: Re: Thread references In-Reply-To: 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 Tue, 2 Nov 1999, Kris Kennaway wrote: > Below are a bunch of papers I was able to dig up last night which > reference the threading models of other OSes, as well as some general > papers. The Solaris implementation papers from Usenix are especially > interesting - I strongly suggest everyone reads at least those, since the > Solaris implementation is probably the "strongest" existing model. > > > Solaris: > > http://www.sun.com/smcc/solaris-migration/docs/courses/threadsHTML/contents.html > http://suncom.bilkent.edu.tr/workshop/sig/threads/ > in particular > http://suncom.bilkent.edu.tr/workshop/sig/threads/usenix.html Yep, these were some of the papers that I've been looking at over the last few months also. I just finished putting them on freefall, but the link you provide looks better :-) Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 13:16:19 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id BCF8A1501B for ; Tue, 2 Nov 1999 13:16:08 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA27217 for ; Tue, 2 Nov 1999 22:16:07 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA82393 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 22:16:06 +0100 (MET) Received: by hub.freebsd.org (Postfix, from userid 758) id B41891501B; Tue, 2 Nov 1999 13:14:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id A84A81CD75C; Tue, 2 Nov 1999 13:14:01 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Tue, 2 Nov 1999 13:14:01 -0800 (PST) From: Kris Kennaway To: "Daniel M. Eischen" Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) In-Reply-To: <381ED720.5A24A02B@vigrid.com> 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 Tue, 2 Nov 1999, Daniel M. Eischen wrote: > Julian Elischer wrote: > > > > Here is an updated version of the rather simplistic requirements for a > > threads model for freeBSD. > [...] > > > > 1/ Multiple independent 'threads of control' within a single process > > at user level. The most basic quality of threads. > > > > 2/ Ability to simultaneously schedule M threads over N Processors, > > and have min(M,N) threads simultaneously executing. > > Shouldn't this be M threads over N [lightweight] Processes? A better wording might be "N virtual processors", or (Terry's terminology) "Kernel Schedulable Entities (KSEs)" to abstract what is used as backing in the kernel, i.e. what actually gets run by the kernel on the physical processors. > How about [from the "scheduler activations" paper] Flexibility? I assume by this you mean "the ability to replace the user-level code with another model". In theory, that's a good goal, and it's one we shouldn't work against, but in practise there's only likely to be one (supported) FreeBSD user-threading library which interfaces to the kernel support. ---- Cthulhu for President! For when you're tired of choosing the _lesser_ of two evils.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 13:28:29 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 82FEF15340 for ; Tue, 2 Nov 1999 13:28:18 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA27326 for ; Tue, 2 Nov 1999 22:28:17 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA82455 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 22:28:17 +0100 (MET) Received: by hub.freebsd.org (Postfix, from userid 758) id 064FB15470; Tue, 2 Nov 1999 13:28:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id ED84C1CD75C; Tue, 2 Nov 1999 13:28:01 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Tue, 2 Nov 1999 13:28:01 -0800 (PST) From: Kris Kennaway To: Julian Elischer Cc: "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) In-Reply-To: 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 Tue, 2 Nov 1999, Julian Elischer wrote: > > Disagree. I want lightweight processes to have their own quantum > > not limited (in total) to the parent process quantum. > > Most people disagree with you on this one, so if you want what you > describe, you will have to thik of a way of decribing it as an optional > characteristic. We discussed this and the overwhelming majority decided > that a threaded program has no real scheduling advantage over a non > threaded program, oth that what it get's by teh nature of blockin gless > and being on multiple CPUs. Having said that, it is possible that you want > your threaded proggram to hog the system (the sysadmin may disagree, in > which case you must still be bound by your process limits). Should this be > the case, you should be able to specify some optional (non > default) characteristic that allows this.. If you can thinkk of a good way > of describing this, we can include it.. (but it can't be the default > behaviour as far as I can see.) If we were using a Solaris-like model where you can have arbitrarily many kernel threads (KSEs) then this shouldn't be the default behaviour, you're right - perhaps we should add a "backwards compatability"/"no breaking of UNIX semantics" item to the list of design goals. If you can generate M>N kernel threads on behalf of your process then you can starve other processes in the system. But I can see that there are situations where you might want this behaviour; to make maximum use of the hardware you (as a process) don't want your various KSEs competing with each other for scheduling quanta, but competing equally with the other KSEs on the system. In terms of scheduler activations, the system ONLY allocates as many "live" (non-blocked) activations (KSEs) as there are processors, so if your process has more than one activation that means it's yours to use until it's taken away from you, independent of whatever other KSEs in your process are doing. So this becomes a non-problem. Kris ---- Cthulhu for President! For when you're tired of choosing the _lesser_ of two evils.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 13:40:37 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id F1A341542A for ; Tue, 2 Nov 1999 13:40:27 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA27444 for ; Tue, 2 Nov 1999 22:40:16 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA82513 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 22:40:11 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id D8D9F1542B; Tue, 2 Nov 1999 13:38:27 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id QAA28092; Tue, 2 Nov 1999 16:37:10 -0500 (EST) Date: Tue, 2 Nov 1999 16:37:09 -0500 (EST) From: Daniel Eischen To: Kris Kennaway Cc: "Daniel M. Eischen" , Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) In-Reply-To: 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 Tue, 2 Nov 1999, Kris Kennaway wrote: > On Tue, 2 Nov 1999, Daniel M. Eischen wrote: > > > How about [from the "scheduler activations" paper] Flexibility? > > I assume by this you mean "the ability to replace the user-level code with > another model". In theory, that's a good goal, and it's one we shouldn't > work against, but in practise there's only likely to be one (supported) > FreeBSD user-threading library which interfaces to the kernel support. But the _same_ threading library can provide different scheduling models (SCHED_RR and SCHED_FIFO). That's kind of what I was after. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 13:42:37 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A2E9E14C35 for ; Tue, 2 Nov 1999 13:42:31 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA27472 for ; Tue, 2 Nov 1999 22:42:29 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA82543 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 22:42:29 +0100 (MET) Received: by hub.freebsd.org (Postfix, from userid 758) id CA90B15438; Tue, 2 Nov 1999 13:40:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id BE8C11CD75C; Tue, 2 Nov 1999 13:40:56 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Tue, 2 Nov 1999 13:40:56 -0800 (PST) From: Kris Kennaway To: "Daniel C. Sobral" Cc: Daniel Eischen , julian@whistle.com, nate@mt.sri.com, freebsd-arch@freebsd.org Subject: Solaris terminology In-Reply-To: <381D8046.812922F6@newsguy.com> 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, 1 Nov 1999, Daniel C. Sobral wrote: > Not sure how are things these days there, but maybe they refer to > lwp as their previous implementation (userland threads) and threads > as their present implementation (kernel threads)? The Solaris terminology seems to be: User threads are scheduled over lightweight processes. Lightweight processors run in the kernel using execution contexts of Kernel Threads. Each LWP gets 1 and only 1 kernel thread, but you can bind N user threads to M LWPs, and M LWPs to P processors. Kernel Threads can also exist without a LWP, i.e. for purely in-kernel tasks like interrupt handling and periodic activities. LWP and KT are therefore more or less interchangable when you're talking about what happens to the process, and just depend on which side of the kernel you're in. Kris ---- Cthulhu for President! For when you're tired of choosing the _lesser_ of two evils.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 14: 5:40 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 09D681546E for ; Tue, 2 Nov 1999 14:05:08 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA27714 for ; Tue, 2 Nov 1999 23:05:05 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA82695 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 23:05:05 +0100 (MET) Received: by hub.freebsd.org (Postfix, from userid 758) id 48C2D1546E; Tue, 2 Nov 1999 14:04:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 3AC0C1CD75C; Tue, 2 Nov 1999 14:04:49 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Tue, 2 Nov 1999 14:04:49 -0800 (PST) From: Kris Kennaway To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) In-Reply-To: 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 Tue, 2 Nov 1999, Julian Elischer wrote: > 2/ Ability to simultaneously schedule M threads over N Processors, > and have min(M,N) threads simultaneously executing. ^ systemwide or in other words, "no processor should be idle if there is an unblocked thread available". > 7/ Some well documeted scheme exists for handling signals and other async > events. The Solaris papers I referred to earlier outline the model they use, which is basically, process-wide thread handlers (not per-thread), but per-thread signal masks. The thread handler can use the thread ID as an index into a lookup table to implement per-thread handling, if desired. The user-level code needs to install handlers which actually receive the signals if any of the (possibly sleeping) threads are waiting for them, and then wake them up or queue the signal as appropriate, and post it to them when they next become active. As for further references, I found out recently that USC has electronic access to a huge array of full-text online journals and resources (e.g. the IEEE online library, the ACM journals dating back to 1985, etc). If anyone is looking for a paper, let me know and I'll see if I can (legally) send it to you. Kris ---- Cthulhu for President! For when you're tired of choosing the _lesser_ of two evils.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 14: 7:25 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 367A51546E for ; Tue, 2 Nov 1999 14:07:16 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA27739 for ; Tue, 2 Nov 1999 23:07:13 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA82722 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 23:07:13 +0100 (MET) Received: by hub.freebsd.org (Postfix, from userid 758) id 1D68715458; Tue, 2 Nov 1999 14:06:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 10CD51CD75C; Tue, 2 Nov 1999 14:06:58 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Tue, 2 Nov 1999 14:06:57 -0800 (PST) From: Kris Kennaway To: Daniel Eischen Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) In-Reply-To: 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 Tue, 2 Nov 1999, Daniel Eischen wrote: > > > How about [from the "scheduler activations" paper] Flexibility? > > > > I assume by this you mean "the ability to replace the user-level code with > > another model". In theory, that's a good goal, and it's one we shouldn't > > work against, but in practise there's only likely to be one (supported) > > FreeBSD user-threading library which interfaces to the kernel support. > > But the _same_ threading library can provide different scheduling models > (SCHED_RR and SCHED_FIFO). That's kind of what I was after. Okay, sure, if that's what gets coded. I kind of figured we'd be lucky to get one model given the complexity of the task, and we'd be stuck with it evermore :-) Kris ---- Cthulhu for President! For when you're tired of choosing the _lesser_ of two evils.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 15:21:49 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C0FF5152F4 for ; Tue, 2 Nov 1999 15:21:39 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA28340 for ; Wed, 3 Nov 1999 00:21:31 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA83003 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 00:21:31 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id AC5EA152F4 for ; Tue, 2 Nov 1999 15:20:01 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id QAA04024; Tue, 2 Nov 1999 16:19:59 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id QAA26200; Tue, 2 Nov 1999 16:19:58 -0700 Date: Tue, 2 Nov 1999 16:19:58 -0700 Message-Id: <199911022319.QAA26200@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) In-Reply-To: <19991102173736.9E34E1FCD@io.yi.org> References: <19991102173736.9E34E1FCD@io.yi.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ Jumping in headlong into this thing, after reading the 'Scheduler Activations paper. I may be a bit confused, so feel free to correct me, but I have a potential issue with the implementation described in the paper. ] First, some background. One of the big reasons that FreeBSD is chosen over other platforms is it's ability to handle heavy loads well. It's both robust *AND* makes very good use of available hardware. The types of loads that FreeBSD excels usually involve lots of I/O (WWW servers, disk farms for video, network servers, etc...). Being able to effeciently pump out *LOTS* of bandwidth in an extremely effecient manner is one of FreeBSD's strengths. We get close-to-hardware speeds for networking performance, file system performance, and the like, and that's one of our big selling points. IMO, any threading solution we implement must maintain this advantage. However, I'm not sure using 'scheduler activation' would allow us to do that well. In particular, the threading model proposed assumes that Activation Upcalls to userland will be minimized. However, in the multi-threaded applications I'm aware, the design tends to have *many* threads, where each thread is responsible for one/more I/O channels (files, sockets, clients, etc...) One of the biggest advantages of kernel threads (vs. userland threads) is that regardless of the type of I/O, a kernel thread can 'block' waiting for data and/or waiting for data to be written while allowing other 'threads' of execution to continue. Therefore, you'd want to have lots of 'kernel threads' active at any one time if you had lots of channels for I/O to occur. (Note, select/poll don't always work, and are not a good 'map' into threading models, IMO. Feel free to point out why I'm out to lunch, as I'd love to have a discussion on this.). So, assuming we're not using select/poll, there are potentially a *LOT* of kernel threads blocked in the kernel. In the SA model, once a 'thread' was blocked in the kernel, an SA (which is in effect the kernel thread) would be passed back via an upcall to the userland scheduler to allow it to continue working on other threads, so the process is allowed to continue using the rest of its quantum. Given that there are N userland threads 'blocked' in the kernel, and M active 'SA' (kernel threads), everytime one of the userland threads 'unblocks' due to I/O coming in or completing, there is potentially a *LOT* of upcall traffic, especially in applications that manage lots of I/O channels (WWW servers, ftp servers, etc..). It would seem to me that the SA model is a poor match for this kind of application, which tends to be the kind of application that FreeBSD is best suited for. What am I missing? Is it just a fact that there is no good threading solution for this kind of application? Solaris seems to do a pretty good job of optimizing this case, although it may be that we have nothing better to compare it to simply because no one has implemented a robust enough implementation on any other OS/hardware platform? Comments appreciated!! Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 15:52:32 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id DFE6314C39 for ; Tue, 2 Nov 1999 15:52:21 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA28604 for ; Wed, 3 Nov 1999 00:52:19 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA83193 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 00:52:19 +0100 (MET) Received: from plunger.gdeb.com (plunger.gdeb.com [153.11.11.3]) by hub.freebsd.org (Postfix) with ESMTP id 0D4F0152F8 for ; Tue, 2 Nov 1999 15:51:56 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from orion.caen.gdeb.com ([153.11.109.11]) by plunger.gdeb.com with ESMTP id SAA12715; Tue, 2 Nov 1999 18:25:22 -0500 (EST) Received: from vigrid.com (clcrtr [153.11.109.129]) by orion.caen.gdeb.com (8.9.3/8.9.3) with ESMTP id SAA45340; Tue, 2 Nov 1999 18:50:07 -0500 (EST) (envelope-from eischen@vigrid.com) Message-ID: <381F78AF.D5073BFB@vigrid.com> Date: Tue, 02 Nov 1999 18:50:07 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.51 [en] (X11; U; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) References: <19991102173736.9E34E1FCD@io.yi.org> <199911022319.QAA26200@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams wrote: > > [ > > Jumping in headlong into this thing, after reading the 'Scheduler > Activations paper. I may be a bit confused, so feel free to correct me, > but I have a potential issue with the implementation described in the > paper. > > ] > > First, some background. One of the big reasons that FreeBSD is chosen > over other platforms is it's ability to handle heavy loads well. It's > both robust *AND* makes very good use of available hardware. > > The types of loads that FreeBSD excels usually involve lots of I/O (WWW > servers, disk farms for video, network servers, etc...). Being able to > effeciently pump out *LOTS* of bandwidth in an extremely effecient > manner is one of FreeBSD's strengths. We get close-to-hardware speeds > for networking performance, file system performance, and the like, and > that's one of our big selling points. > > IMO, any threading solution we implement must maintain this advantage. > > However, I'm not sure using 'scheduler activation' would allow us to do > that well. In particular, the threading model proposed assumes that > Activation Upcalls to userland will be minimized. > > However, in the multi-threaded applications I'm aware, the design tends > to have *many* threads, where each thread is responsible for one/more > I/O channels (files, sockets, clients, etc...) > > One of the biggest advantages of kernel threads (vs. userland threads) > is that regardless of the type of I/O, a kernel thread can 'block' > waiting for data and/or waiting for data to be written while allowing > other 'threads' of execution to continue. Therefore, you'd want to have > lots of 'kernel threads' active at any one time if you had lots of > channels for I/O to occur. (Note, select/poll don't always work, and > are not a good 'map' into threading models, IMO. Feel free to point out > why I'm out to lunch, as I'd love to have a discussion on this.). > > So, assuming we're not using select/poll, there are potentially a *LOT* > of kernel threads blocked in the kernel. In the SA model, once a > 'thread' was blocked in the kernel, an SA (which is in effect the kernel > thread) would be passed back via an upcall to the userland scheduler to > allow it to continue working on other threads, so the process is allowed > to continue using the rest of its quantum. > > Given that there are N userland threads 'blocked' in the kernel, and M > active 'SA' (kernel threads), everytime one of the userland threads > 'unblocks' due to I/O coming in or completing, there is potentially a > *LOT* of upcall traffic, especially in applications that manage lots of > I/O channels (WWW servers, ftp servers, etc..). > > It would seem to me that the SA model is a poor match for this kind of > application, which tends to be the kind of application that FreeBSD is > best suited for. > > What am I missing? Is it just a fact that there is no good threading > solution for this kind of application? Solaris seems to do a pretty > good job of optimizing this case, although it may be that we have > nothing better to compare it to simply because no one has implemented a > robust enough implementation on any other OS/hardware platform? It could also take many kernel wakeups for a heavy I/O bound thread to leave the kernel. I thought of this ;-). This is how binding a thread to a LWP can be useful. For a thread bound to a LWP, you only notify the user level threads library if it blocks because it's time quantum expired (so the threads library can see if it is in a critical region). If the thread blocks due to a tsleep or something like that, you can assume it's not holding any critical resources that the user threads library implementation needs. In this case, you don't notify the threads library. So by extending SA to allow binding threads to LWPs, you can achieve just about the same thing as async call gates. But it's the application that gets to decide exactly how to use these features, and not left to the implementation in the kernel. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 15:57:24 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id EDFF414C39 for ; Tue, 2 Nov 1999 15:57:19 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA28640 for ; Wed, 3 Nov 1999 00:57:18 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA83234 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 00:57:18 +0100 (MET) Received: from plunger.gdeb.com (plunger.gdeb.com [153.11.11.3]) by hub.freebsd.org (Postfix) with ESMTP id A928114FBD for ; Tue, 2 Nov 1999 15:57:08 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from orion.caen.gdeb.com ([153.11.109.11]) by plunger.gdeb.com with ESMTP id SAA12799; Tue, 2 Nov 1999 18:30:37 -0500 (EST) Received: from vigrid.com (clcrtr [153.11.109.129]) by orion.caen.gdeb.com (8.9.3/8.9.3) with ESMTP id SAA45353; Tue, 2 Nov 1999 18:55:23 -0500 (EST) (envelope-from eischen@vigrid.com) Message-ID: <381F79EB.F4D206B6@vigrid.com> Date: Tue, 02 Nov 1999 18:55:23 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.51 [en] (X11; U; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams , Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) References: <19991102173736.9E34E1FCD@io.yi.org> <199911022319.QAA26200@mt.sri.com> <381F78AF.D5073BFB@vigrid.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel M. Eischen" wrote: > > It could also take many kernel wakeups for a heavy I/O bound thread to > leave the kernel. I thought of this ;-). > > This is how binding a thread to a LWP can be useful. For a thread bound > to a LWP, you only notify the user level threads library if it blocks because > it's time quantum expired (so the threads library can see if it is in a > critical region). If the thread blocks due to a tsleep or something like > that, you can assume it's not holding any critical resources that the user > threads library implementation needs. In this case, you don't notify the > threads library. > > So by extending SA to allow binding threads to LWPs, you can achieve just > about the same thing as async call gates. But it's the application that gets > to decide exactly how to use these features, and not left to the implementation > in the kernel. Sorry, there I go again using LWP. Please replace LWP with Nate's chosen terminology 'kernel thread'. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 16:16:35 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id E8C4814CB0 for ; Tue, 2 Nov 1999 16:16:30 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id BAA28780 for ; Wed, 3 Nov 1999 01:16:29 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA83297 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 01:16:29 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 4C31614CB0 for ; Tue, 2 Nov 1999 16:16:16 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id RAA04716; Tue, 2 Nov 1999 17:16:13 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id RAA26726; Tue, 2 Nov 1999 17:16:12 -0700 Date: Tue, 2 Nov 1999 17:16:12 -0700 Message-Id: <199911030016.RAA26726@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Daniel M. Eischen" Cc: Nate Williams , Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) In-Reply-To: <381F78AF.D5073BFB@vigrid.com> References: <19991102173736.9E34E1FCD@io.yi.org> <199911022319.QAA26200@mt.sri.com> <381F78AF.D5073BFB@vigrid.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ My assertion that Scheduler Activations isn't a good solution for heavy I/O applications ] > > What am I missing? Is it just a fact that there is no good threading > > solution for this kind of application? Solaris seems to do a pretty > > good job of optimizing this case, although it may be that we have > > nothing better to compare it to simply because no one has implemented a > > robust enough implementation on any other OS/hardware platform? > > It could also take many kernel wakeups for a heavy I/O bound thread to > leave the kernel. I thought of this ;-). > > This is how binding a thread to a LWP can be useful. [ I'm assuming that LWP == kernel thread ] Then we're no longer using SA, and we're more like the Solaris model, as I understand it. At this point, you'd have *LOTS* more threads than available processors, because it is expected to have lots of LWP's blocked in the kernel. > For a thread bound to a LWP, you only notify the user level threads > library if it blocks because it's time quantum expired (so the threads > library can see if it is in a critical region). They talk about this in the paper, and I don't like their solution. Having to modify the compiler/assembler and such is not a workable solution, IMO. > If the thread blocks due to a tsleep or something like > that, you can assume it's not holding any critical resources that the user > threads library implementation needs. In this case, you don't notify the > threads library. Maybe, maybe not. It still might be holding onto a critical resource that it obtained while in userland. /* Only allow the one thread to modify the shared buffer */ aquire_critical_resource(); read(); release_critical_resource(); Granted, my example is a bad design if I'm expecting the read call to block, but I'm sure there are good designs that may still use this, especially in the case where *most* of the time the thread won't block, so it allows you to optimize the common case. > So by extending SA to allow binding threads to LWPs, you can achieve > just about the same thing as async call gates. But it's the > application that gets to decide exactly how to use these features, and > not left to the implementation in the kernel. The idea of being 'too flexible' scares me. Writing correct threaded code is hard, when you start throwing in the complexity of determining thread scheduler models, types of threads to create, etc..., and all of a sudden multi-process solutions start to look pretty good. My reason for writing multi-threaded code is more often ease of implementation and maintainability. When something is easier to implement, it also tends to be more effecient, since you can spend more time 'optimizing' it, instead of spending all of your time making it correct. But, that's a personal soapbox, and may not be appropriate for FreeBSD.... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 16:47:34 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 88F7215360 for ; Tue, 2 Nov 1999 16:47:30 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id BAA29002 for ; Wed, 3 Nov 1999 01:47:29 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA83397 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 01:47:28 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id CB57915360 for ; Tue, 2 Nov 1999 16:47:21 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt96.pcnet.net [206.105.29.170]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id TAA22417; Tue, 2 Nov 1999 19:46:01 -0500 (EST) Message-ID: <381F85F2.BF6D5A2@vigrid.com> Date: Tue, 02 Nov 1999 19:46:42 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) References: <19991102173736.9E34E1FCD@io.yi.org> <199911022319.QAA26200@mt.sri.com> <381F78AF.D5073BFB@vigrid.com> <199911030016.RAA26726@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams wrote: > > [ My assertion that Scheduler Activations isn't a good solution for > heavy I/O applications ] > > > > What am I missing? Is it just a fact that there is no good threading > > > solution for this kind of application? Solaris seems to do a pretty > > > good job of optimizing this case, although it may be that we have > > > nothing better to compare it to simply because no one has implemented a > > > robust enough implementation on any other OS/hardware platform? > > > > It could also take many kernel wakeups for a heavy I/O bound thread to > > leave the kernel. I thought of this ;-). > > > > This is how binding a thread to a LWP can be useful. > > [ I'm assuming that LWP == kernel thread ] > > Then we're no longer using SA, and we're more like the Solaris model, as > I understand it. At this point, you'd have *LOTS* more threads than > available processors, because it is expected to have lots of LWP's > blocked in the kernel. The application decides what threads are bound to kernel threads. It can bind as many threads as it wants (within process limits) to kernel threads. It need not bind them all unless it wants to. > > > For a thread bound to a LWP, you only notify the user level threads > > library if it blocks because it's time quantum expired (so the threads > > library can see if it is in a critical region). > > They talk about this in the paper, and I don't like their solution. > Having to modify the compiler/assembler and such is not a workable > solution, IMO. No, I didn't either, but you can still get the same thing by manually coding each routine. You could also set flags instead with not too much more overhead. > > If the thread blocks due to a tsleep or something like > > that, you can assume it's not holding any critical resources that the user > > threads library implementation needs. In this case, you don't notify the > > threads library. > > Maybe, maybe not. It still might be holding onto a critical resource > that it obtained while in userland. This is really only a concern in the threads library implementation where you are using internal resources such as spinlocks or mutexes to protect scheduling queues, file descriptor lock tables, etc. The threads library would be coded to prevent calling blocking system calls while holding such resources. All other (visible) resources are the responsibility of the application. > The idea of being 'too flexible' scares me. Writing correct threaded > code is hard, when you start throwing in the complexity of determining > thread scheduler models, types of threads to create, etc..., and all of > a sudden multi-process solutions start to look pretty good. Well, stick with what you know then ;-) And also make sure whatever we do gets sufficiently documented! > My reason for writing multi-threaded code is more often ease of > implementation and maintainability. When something is easier to > implement, it also tends to be more effecient, since you can spend more > time 'optimizing' it, instead of spending all of your time making it > correct. > > But, that's a personal soapbox, and may not be appropriate for > FreeBSD.... :-) Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 20:25:10 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 031E614C39 for ; Tue, 2 Nov 1999 20:25:06 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA02923 for ; Wed, 3 Nov 1999 05:25:05 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA84281 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 05:25:05 +0100 (MET) Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id DC98E154D6 for ; Tue, 2 Nov 1999 20:24:26 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id UAA29559; Tue, 2 Nov 1999 20:24:25 -0800 (PST) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id UAA47266; Tue, 2 Nov 1999 20:24:25 -0800 (PST) (envelope-from jdp@polstra.com) Date: Tue, 2 Nov 1999 20:24:25 -0800 (PST) Message-Id: <199911030424.UAA47266@vashon.polstra.com> To: eischen@vigrid.com Subject: Re: Threads models and FreeBSD. (Next Step) In-Reply-To: <381F85F2.BF6D5A2@vigrid.com> References: <381F78AF.D5073BFB@vigrid.com> <199911030016.RAA26726@mt.sri.com> <381F85F2.BF6D5A2@vigrid.com> Organization: Polstra & Co., Seattle, WA Cc: arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <381F85F2.BF6D5A2@vigrid.com>, Daniel M. Eischen wrote: > Nate Williams wrote: > > > > > For a thread bound to a LWP, you only notify the user level threads > > > library if it blocks because it's time quantum expired (so the threads > > > library can see if it is in a critical region). > > > > They talk about this in the paper, and I don't like their solution. > > Having to modify the compiler/assembler and such is not a workable > > solution, IMO. > > No, I didn't either, but you can still get the same thing by manually > coding each routine. You could also set flags instead with not too > much more overhead. I've just been looking at the paper, and I don't think they modified the compiler or the assembler. What they say is: We do this by delimiting, with special assembler labels, each critical section in the C source code for the user-level thread package; we then post-process the compiler-generated assembly code to make the copy. I think the "delimiting, with special assembler labels" is simply the addition of some asm statements to the C source code of their libc_r threads kernel equivalent. The second part, "post-process the compiler-generated assembly code," is just a little program or shell/awk/sed/perl script and some fancy Makefile rules. All they are aiming for is a table of PC ranges that they can consult at run time to determine whether the thread was in a critical section when it blocked or was pre-empted. That's easy to get without modifying the compiler or assembler -- especially with ELF, where we can put the table into a separate section. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "No matter how cynical I get, I just can't keep up." -- Nora Ephron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 20:26:42 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 84B1014C39 for ; Tue, 2 Nov 1999 20:26:36 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA02941 for ; Wed, 3 Nov 1999 05:26:35 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA84303 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 05:26:34 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 14BE714C39 for ; Tue, 2 Nov 1999 20:26:24 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id UAA16380; Tue, 2 Nov 1999 20:26:19 -0800 (PST) Date: Tue, 2 Nov 1999 20:26:18 -0800 (PST) From: Julian Elischer To: "Daniel M. Eischen" Cc: Nate Williams , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) In-Reply-To: <381F85F2.BF6D5A2@vigrid.com> 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 I don't know about the rest of you but I'm busy reading :-) this thread is NOT dead ... :-) (just in case anyone thought that..) julian On Tue, 2 Nov 1999, Daniel M. Eischen wrote: > Nate Williams wrote: > > > > [ My assertion that Scheduler Activations isn't a good solution for > > heavy I/O applications ] > > > > > > What am I missing? Is it just a fact that there is no good threading > > > > solution for this kind of application? Solaris seems to do a pretty > > > > good job of optimizing this case, although it may be that we have > > > > nothing better to compare it to simply because no one has implemented a > > > > robust enough implementation on any other OS/hardware platform? > > > > > > It could also take many kernel wakeups for a heavy I/O bound thread to > > > leave the kernel. I thought of this ;-). > > > > > > This is how binding a thread to a LWP can be useful. > > > > [ I'm assuming that LWP == kernel thread ] > > > > Then we're no longer using SA, and we're more like the Solaris model, as > > I understand it. At this point, you'd have *LOTS* more threads than > > available processors, because it is expected to have lots of LWP's > > blocked in the kernel. > > The application decides what threads are bound to kernel threads. It > can bind as many threads as it wants (within process limits) to kernel > threads. It need not bind them all unless it wants to. > > > > > > For a thread bound to a LWP, you only notify the user level threads > > > library if it blocks because it's time quantum expired (so the threads > > > library can see if it is in a critical region). > > > > They talk about this in the paper, and I don't like their solution. > > Having to modify the compiler/assembler and such is not a workable > > solution, IMO. > > No, I didn't either, but you can still get the same thing by manually > coding each routine. You could also set flags instead with not too > much more overhead. > > > > If the thread blocks due to a tsleep or something like > > > that, you can assume it's not holding any critical resources that the user > > > threads library implementation needs. In this case, you don't notify the > > > threads library. > > > > Maybe, maybe not. It still might be holding onto a critical resource > > that it obtained while in userland. > > This is really only a concern in the threads library implementation > where you are using internal resources such as spinlocks or mutexes > to protect scheduling queues, file descriptor lock tables, etc. The > threads library would be coded to prevent calling blocking system calls > while holding such resources. > > All other (visible) resources are the responsibility of the application. > > > The idea of being 'too flexible' scares me. Writing correct threaded > > code is hard, when you start throwing in the complexity of determining > > thread scheduler models, types of threads to create, etc..., and all of > > a sudden multi-process solutions start to look pretty good. > > Well, stick with what you know then ;-) And also make sure whatever > we do gets sufficiently documented! > > > My reason for writing multi-threaded code is more often ease of > > implementation and maintainability. When something is easier to > > implement, it also tends to be more effecient, since you can spend more > > time 'optimizing' it, instead of spending all of your time making it > > correct. > > > > But, that's a personal soapbox, and may not be appropriate for > > FreeBSD.... > > :-) > > Dan Eischen > eischen@vigrid.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 2 23:26: 7 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3344715505 for ; Tue, 2 Nov 1999 23:26:04 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id IAA04231 for ; Wed, 3 Nov 1999 08:25:59 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA84886 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 08:25:59 +0100 (MET) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (Postfix) with ESMTP id 374B115505 for ; Tue, 2 Nov 1999 23:25:48 -0800 (PST) (envelope-from michael.schuster@germany.sun.com) Received: from emuc05-home.Germany.Sun.COM ([129.157.51.10]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA23615 for ; Tue, 2 Nov 1999 23:25:47 -0800 (PST) Received: from germany.sun.com (hacker [129.157.167.97]) by emuc05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with ESMTP id IAA15904 for ; Wed, 3 Nov 1999 08:25:44 +0100 (MET) Message-ID: <381FE37A.736B5D9E@germany.sun.com> Date: Wed, 03 Nov 1999 08:25:46 +0100 From: Michael Schuster - TSC SunOS Germany Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: Solaris terminology References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kris Kennaway wrote: > The Solaris terminology seems to be: An illustration can be found here: http://www.sun.com/smcc/solaris-migration/docs/courses/threadsHTML/intro.html#846832 though the artwork leaves to be desired, it may help visualize the concept. > User threads are scheduled over lightweight processes. Lightweight > processors run in the kernel using execution contexts of Kernel Threads. > Each LWP gets 1 and only 1 kernel thread, but you can bind N user threads > to M LWPs, and M LWPs to P processors. > > Kernel Threads can also exist without a LWP, i.e. for purely in-kernel > tasks like interrupt handling and periodic activities. clock thread and memscrubber are an example for this, these are threads ps doesn't show. > LWP and KT are therefore more or less interchangable when you're talking > about what happens to the process, and just depend on which side of the > kernel you're in. I'd rather say "which side of the syscall boundary you're on", but your meaning is clear :-) > Kris cheers Michael -- Michael Schuster / Michael.Schuster@germany.sun.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 3 0: 2:25 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 653D514E81 for ; Wed, 3 Nov 1999 00:02:22 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id JAA04741 for ; Wed, 3 Nov 1999 09:01:41 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA85010 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 09:01:39 +0100 (MET) Received: from rah.star-gate.com (216-200-29-190.snj0.flashcom.net [216.200.29.194]) by hub.freebsd.org (Postfix) with ESMTP id 8647114F10 for ; Wed, 3 Nov 1999 00:01:32 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.3/8.8.8) with ESMTP id AAA33669 for ; Wed, 3 Nov 1999 00:00:39 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199911030800.AAA33669@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-arch@freebsd.org Subject: Re: Solaris terminology In-reply-to: Your message of "Wed, 03 Nov 1999 08:25:46 +0100." <381FE37A.736B5D9E@germany.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Nov 1999 00:00:39 -0800 From: Amancio Hasty Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG BTW: SGI is supposed to be working on Linux to make it more scalable across multiple processors . The figure that I heard is that they were aiming for 100 processors or so . Since SGIs work is supposed to be "open-source" perhaps someone can dig up what SGI is up to ... -- Amancio Hasty hasty@rah.star-gate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 3 2:13:19 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A786514F51 for ; Wed, 3 Nov 1999 02:13:17 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id LAA06846 for ; Wed, 3 Nov 1999 11:13:16 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA85744 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 11:13:16 +0100 (MET) Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 658EE14F51; Wed, 3 Nov 1999 02:13:06 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id KAA41359; Wed, 3 Nov 1999 10:13:29 GMT (envelope-from dfr@nlsystems.com) Date: Wed, 3 Nov 1999 10:13:28 +0000 (GMT) From: Doug Rabson To: Kris Kennaway Cc: arch@freebsd.org Subject: Re: Thread references In-Reply-To: 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 Tue, 2 Nov 1999, Kris Kennaway wrote: > Below are a bunch of papers I was able to dig up last night which > reference the threading models of other OSes, as well as some general > papers. The Solaris implementation papers from Usenix are especially > interesting - I strongly suggest everyone reads at least those, since the > Solaris implementation is probably the "strongest" existing model. > > Something I'm unclear on though is whether that information is protected > by patents or whether by publishing in the usenix proceedings it becomes > an open source, and so whether we're allowed to refer to it in our own > design. If the patent was applied for before the disclosure, then I think they could be protected (I have no idea whether any of these technologies is encumbered by patents). -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 3 5:47:46 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 36F351508E for ; Wed, 3 Nov 1999 05:47:43 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id OAA10451 for ; Wed, 3 Nov 1999 14:47:42 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA86997 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 14:47:41 +0100 (MET) Received: from test.tar.com (test.tar.com [204.95.187.4]) by hub.freebsd.org (Postfix) with ESMTP id 2809D1559D for ; Wed, 3 Nov 1999 05:46:55 -0800 (PST) (envelope-from dick@test.tar.com) Received: (from dick@localhost) by test.tar.com (8.9.3/8.9.3) id HAA32877; Wed, 3 Nov 1999 07:46:52 -0600 (CST) (envelope-from dick) Date: Wed, 3 Nov 1999 07:46:52 -0600 From: "Richard Seaman, Jr." To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) Message-ID: <19991103074651.E5715@tar.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Nov 02, 1999 at 12:59:28AM -0800, Julian Elischer wrote: [....] > ---- possible userland implementation goals----- > > 1/ A libpthread that can be linked with libc. > > 2/ Libc needs to change so that library functions and system calls > used internal to the library do not use the externally visible > cancellable equivalents. Can I suggest in addition to 2: a) libc that is thread safe when used with libpthread (currently libc is only partly thread safe, and even libc_r is not completely thread safe). b) hooks in libc to facilitate thread safe behaviour, specifically libc structures that include locks, or pointers to locks as part of the strcuture. This will probably require a version bump for libc, but the alternative is really ugly (see John Birrell's implementation of locking for the FILE structure as an example of what will have to be repeated for other libc structures without locks as part of the structures). As a 3) can I suggest: User land "system" libraries that are thread aware and thread safe (libgcc is an example of one that is needed -- perhaps there are others) when used with threaded applications As a 4) can I suggest: Debugger support for threads. As a 5) can I suggest: Well defined and industry standard methods for compiling and linking threaded applications (currently FreeBSD's libc_r requirements for compile/link are different from the most commonly used methods in other pthreads implementations. Just browse through the ports to see what FreeBSD specific changes have to be made to port threaded applications. If we used more convetional compile/link requirements, porting would be much easier). -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 3 6:27:29 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 567C514F85 for ; Wed, 3 Nov 1999 06:27:24 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id PAA11140 for ; Wed, 3 Nov 1999 15:27:22 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA87151 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 15:27:07 +0100 (MET) Received: from gilgamesch.bik-gmbh.de (gilgamesch.bik-gmbh.de [194.233.237.194]) by hub.freebsd.org (Postfix) with ESMTP id 19B0F14F85; Wed, 3 Nov 1999 06:26:37 -0800 (PST) (envelope-from cracauer@gilgamesch.bik-gmbh.de) Received: (from cracauer@localhost) by gilgamesch.bik-gmbh.de (8.9.3/8.7.3) id PAA12043; Wed, 3 Nov 1999 15:26:35 +0100 (MET) Date: Wed, 3 Nov 1999 15:26:35 +0100 From: Martin Cracauer To: "David O'Brien" Cc: Randell Jesup , freebsd-arch@freebsd.org Subject: Re: stpcpy() Message-ID: <19991103152634.A11781@cons.org> References: <199910312349.CAA02684@tejblum.pp.ru> <19991031230542.B10904@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <19991031230542.B10904@dragon.nuxi.com>; from David O'Brien on Sun, Oct 31, 1999 at 11:05:42PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In <19991031230542.B10904@dragon.nuxi.com>, David O'Brien wrote: > > I'll bet 95% of programmers working on systems where stpcpy has been > > part of the libraries for a long time don't even know that it isn't > > standard. > > I don't doubt that. Other than BDE and myself, I don't even know of > anyone that even has the ANSI-C standard. There's the "Annotated ANSI C standard", which delivers the verbatim ANSI C document (with some support stuff missing, I think) for a normal book's price. It serves quite well if you ignore the annotations. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 3 6:34:45 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3CE6015583 for ; Wed, 3 Nov 1999 06:34:41 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id PAA11283 for ; Wed, 3 Nov 1999 15:34:39 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA87187 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 15:34:39 +0100 (MET) Received: from gilgamesch.bik-gmbh.de (gilgamesch.bik-gmbh.de [194.233.237.194]) by hub.freebsd.org (Postfix) with ESMTP id 6E638155B0 for ; Wed, 3 Nov 1999 06:34:03 -0800 (PST) (envelope-from cracauer@gilgamesch.bik-gmbh.de) Received: (from cracauer@localhost) by gilgamesch.bik-gmbh.de (8.9.3/8.7.3) id PAA12138; Wed, 3 Nov 1999 15:33:32 +0100 (MET) Date: Wed, 3 Nov 1999 15:33:32 +0100 From: Martin Cracauer To: Poul-Henning Kamp Cc: chris@calldei.com, Randell Jesup , freebsd-arch@freebsd.org Subject: Re: stpcpy() Message-ID: <19991103153332.B11781@cons.org> References: <19991029151317.E535@holly.calldei.com> <6166.941228175@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <6166.941228175@critter.freebsd.dk>; from Poul-Henning Kamp on Fri, Oct 29, 1999 at 10:16:15PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In <6166.941228175@critter.freebsd.dk>, Poul-Henning Kamp wrote: > Sounds to me like it's time to add these things to liblinuxcompat.a ? You would need an additional header file as well, unless you plan to support something ugly like gcc -DINCLUDE_LINUXSTUFF_FROM_STRING_H bla.c which would clutter up our include files. (Adding this like proposed here to our stdnard include files without guarding from macros is out of question, IMHO). Otherwise, you would have to edit the C files that use the new functions to include new headers, which is more work than a -lbla solution implies. Hm, I should go and fix linux_devel for ELF finally... Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 3 6:58:41 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 10CAF14C4C for ; Wed, 3 Nov 1999 06:58:35 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id PAA11760 for ; Wed, 3 Nov 1999 15:58:29 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA87293 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 15:58:28 +0100 (MET) Received: from bachue.usc.unal.edu.co (bachue.usc.unal.edu.co [168.176.3.20]) by hub.freebsd.org (Postfix) with ESMTP id 1136414CB1 for ; Wed, 3 Nov 1999 06:58:17 -0800 (PST) (envelope-from pfgiffun@bachue.usc.unal.edu.co) Received: from bachue.usc.unal.edu.co ([168.176.3.59]) by bachue.usc.unal.edu.co (Netscape Messaging Server 3.6) with ESMTP id AAA328F; Wed, 3 Nov 1999 08:57:14 -0500 Message-ID: <38204F5E.3EFDDD9E@bachue.usc.unal.edu.co> Date: Wed, 03 Nov 1999 10:06:06 -0500 From: "Pedro Fernando Giffuni" Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Randell Jesup Cc: freebsd-arch@freebsd.org Subject: Re: Compatibility libraries References: <199910312349.CAA02684@tejblum.pp.ru> <99Nov2.073444est.40351@border.alcanet.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG FWIW, I submitted a PR with itoa() some time ago. Being an unstandard thing, based on a Borland compiler, I though it could be a good thing for -lcompat. strcpy() probably belongs to this category also, and since we are only talking about one or maybe two functions, a new compatibility library doesn't seem necessary. Another option would be porting glibc (yucks) to FreeBSD. That would cover any linux compatibility requirement ;-). However there have not been real world examples of neither of these being required in UNIX. Pedro. Randell Jesup wrote: > > Peter Jeremy writes: > >> While non-ANSI standard, this particular function has been > >>virtually standard in PC compilers for a Long Time. > > > >I don't have it in front of me, but I'm fairly certain that my > >Amiga Lattice C manual lists it as a Lattice extension. Given > >that (AFAIK) M$ C started as Lattice C, I wouldn't be surprised > >if it started with Lattice. Matthew Dillon or bde (as long time > >compiler writers) might be able to offer further insight into > >its ancestry. > > Yes, I think it did start in Lattice (later SAS, then Lattice > again). I should ask John Toebes, one of the former SAS/Lattice compiler > people. I think a number of other popular DOS/Win/OS2 compilers added > it also. It might have originated there, though I think I remember > a reference to it in Dr. Dobbs in an article by Tom Holub back around > '84-85ish (on a pseudo-Cshell implementation?) > > I seem (vaguely) to remember him saying that stpcpy made a > measurable difference in a pass of the compiler (preprocessor I suspect). > Also this was admittedly on a 7MHz 68000 platform. > > >I don't recall ever seeing it in a Unix library (ignoring Linux for > >the time being) - which is probably more relevant here. > > True. > > >Overall, I would not like to see stpcpy() appear in libc, though I > >have nothing against it being included in some compatibility library. > > I bow to the assembled opinions and agree. I'd thought it was a > bit more ubiquitous than it is, given it's in Linux now. > > So, what additional libraries should we have, and what should be in > them? I don't like the "add the code to each port" solution a lot, since > unless the code is standardized, there's a considerable chance for Stupid > Coding Mistakes, not to mention potentially lots of time for the porter to > write (or track down) the source for various portability functions. Sounds > like a good case for libraries. Alternatively, we could have standardized > source-code libraries for use by porters. The downside is that bugfixes > and implementation updates to match the underlying OS become a PAIN to > integrate; and to a lesser extent runtime-bloat. > > -- > Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) > rjesup@wgate.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 3 7: 3:38 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0C96014C4C for ; Wed, 3 Nov 1999 07:03:35 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id QAA11872 for ; Wed, 3 Nov 1999 16:03:34 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA87336 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 16:03:34 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id CE72C14C4C for ; Wed, 3 Nov 1999 07:03:24 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id IAA11806; Wed, 3 Nov 1999 08:03:21 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id IAA08453; Wed, 3 Nov 1999 08:03:20 -0700 Date: Wed, 3 Nov 1999 08:03:20 -0700 Message-Id: <199911031503.IAA08453@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: John Polstra Cc: eischen@vigrid.com, arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) In-Reply-To: <199911030424.UAA47266@vashon.polstra.com> References: <381F78AF.D5073BFB@vigrid.com> <199911030016.RAA26726@mt.sri.com> <381F85F2.BF6D5A2@vigrid.com> <199911030424.UAA47266@vashon.polstra.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > For a thread bound to a LWP, you only notify the user level threads > > > > library if it blocks because it's time quantum expired (so the threads > > > > library can see if it is in a critical region). > > > > > > They talk about this in the paper, and I don't like their solution. > > > Having to modify the compiler/assembler and such is not a workable > > > solution, IMO. > > > > No, I didn't either, but you can still get the same thing by manually > > coding each routine. You could also set flags instead with not too > > much more overhead. > > I've just been looking at the paper, and I don't think they modified > the compiler or the assembler. What they say is: > > We do this by delimiting, with special assembler labels, each > critical section in the C source code for the user-level thread > package; we then post-process the compiler-generated assembly > code to make the copy. Correct, but right after that, they stated that instead of having to specially annotate critical sections with assembler labels, it could be picked up automatically with the use of a modified compiler/assembler. Also, either way requires that the program be written in C/C++, which is unacceptable to me (and you I suspect), since some of my 'threaded' programs won't be written in C (Java) and you (Modula-3). These 'critical sections' will exist in Java, and I don't want to re-write the JVM to go figure out what sections are critical and have it build assembly versions. > All they are aiming for is a table of PC ranges that they can consult > at run time to determine whether the thread was in a critical section > when it blocked or was pre-empted. That's easy to get without > modifying the compiler or assembler -- especially with ELF, where we > can put the table into a separate section. See above. If the language you are using to write this stuff in isn't C/C++, it's not quite as straightforward. If you start coding anything that might be critical with the special assembly statements, you lose *much* (or all) of the performance gains that were given before since the VM can't differentiate between a 'critical' section of the code and a non-critical section of the code w/out alot of work, thus making many parts of the code 'critical' just in case. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 3 7:26: 6 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id E968114D1B for ; Wed, 3 Nov 1999 07:26:03 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id QAA12297 for ; Wed, 3 Nov 1999 16:24:46 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA87424 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 16:24:45 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 65A8814D1B for ; Wed, 3 Nov 1999 07:24:01 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id IAA11971; Wed, 3 Nov 1999 08:23:36 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id IAA08555; Wed, 3 Nov 1999 08:23:35 -0700 Date: Wed, 3 Nov 1999 08:23:35 -0700 Message-Id: <199911031523.IAA08555@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Daniel M. Eischen" Cc: Nate Williams , Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) In-Reply-To: <381F85F2.BF6D5A2@vigrid.com> References: <19991102173736.9E34E1FCD@io.yi.org> <199911022319.QAA26200@mt.sri.com> <381F78AF.D5073BFB@vigrid.com> <199911030016.RAA26726@mt.sri.com> <381F85F2.BF6D5A2@vigrid.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The idea of being 'too flexible' scares me. Writing correct threaded > > code is hard, when you start throwing in the complexity of determining > > thread scheduler models, types of threads to create, etc..., and all of > > a sudden multi-process solutions start to look pretty good. > > Well, stick with what you know then ;-) And also make sure whatever > we do gets sufficiently documented! You're missing my point. Writing correct threaded code is hard, and if we make it too difficult, it will have *very* little effect on the userbase, since very few people will be able to write code for FreeBSD. Highly motivated individuals will be able to write code, but if we come up with a very complicated design that requires lots of extra work, very few people will be able to use the new threaded features of FreeBSD. My plea is to keep is simple. KISS rules here, and although flexibility is a grand goal, KISS should always win out. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 3 8:32: 5 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 63D671506B for ; Wed, 3 Nov 1999 08:32:00 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id RAA13313 for ; Wed, 3 Nov 1999 17:31:56 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA87806 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 17:31:55 +0100 (MET) Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id EC2111506B for ; Wed, 3 Nov 1999 08:29:54 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id IAA02774; Wed, 3 Nov 1999 08:28:16 -0800 (PST) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id IAA48687; Wed, 3 Nov 1999 08:28:15 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199911031503.IAA08453@mt.sri.com> Date: Wed, 03 Nov 1999 08:28:15 -0700 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: Nate Williams Subject: Re: Threads models and FreeBSD. (Next Step) Cc: arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams wrote: >> >> I've just been looking at the paper, and I don't think they modified >> the compiler or the assembler. What they say is: >> >> We do this by delimiting, with special assembler labels, each >> critical section in the C source code for the user-level thread >> package; we then post-process the compiler-generated assembly >> code to make the copy. > > Correct, but right after that, they stated that instead of having to > specially annotate critical sections with assembler labels, it could be > picked up automatically with the use of a modified compiler/assembler. It could be done that way, but it doesn't need to be. > Also, either way requires that the program be written in C/C++, > which is unacceptable to me (and you I suspect), since some of my > 'threaded' programs won't be written in C (Java) and you (Modula-3). > These 'critical sections' will exist in Java, and I don't want to > re-write the JVM to go figure out what sections are critical and > have it build assembly versions. No, they say "each critical section in the C source code -->>> for the user-level thread package <<<--". They don't do anything special to application programs. They only mess with the threads kernel (src/lib/libc_r/uthread/uthread_kern.c) itself. It boils down to surrounding certain small sections of code in libc_r with __pthread_begin_critical(); [...] __pthread_end_critical(); (Pick your favorite name for the macros.) John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "No matter how cynical I get, I just can't keep up." -- Nora Ephron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 3 9: 0: 6 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 8DFC714DCB for ; Wed, 3 Nov 1999 09:00:03 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id RAA13605 for ; Wed, 3 Nov 1999 17:59:27 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA87918 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 17:59:24 +0100 (MET) Received: from plunger.gdeb.com (plunger.gdeb.com [153.11.11.3]) by hub.freebsd.org (Postfix) with ESMTP id 2AEEE14E57 for ; Wed, 3 Nov 1999 08:59:12 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from orion.caen.gdeb.com ([153.11.109.11]) by plunger.gdeb.com with ESMTP id LAA02681; Wed, 3 Nov 1999 11:55:06 -0500 (EST) Received: from vigrid.com (clcrtr [153.11.109.129]) by orion.caen.gdeb.com (8.9.3/8.9.3) with ESMTP id LAA46377; Wed, 3 Nov 1999 11:57:22 -0500 (EST) (envelope-from eischen@vigrid.com) Message-ID: <38206971.8D69C9E2@vigrid.com> Date: Wed, 03 Nov 1999 11:57:21 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.51 [en] (X11; U; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) References: <19991102173736.9E34E1FCD@io.yi.org> <199911022319.QAA26200@mt.sri.com> <381F78AF.D5073BFB@vigrid.com> <199911030016.RAA26726@mt.sri.com> <381F85F2.BF6D5A2@vigrid.com> <199911031523.IAA08555@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams wrote: > > > > The idea of being 'too flexible' scares me. Writing correct threaded > > > code is hard, when you start throwing in the complexity of determining > > > thread scheduler models, types of threads to create, etc..., and all of > > > a sudden multi-process solutions start to look pretty good. > > > > Well, stick with what you know then ;-) And also make sure whatever > > we do gets sufficiently documented! > > You're missing my point. Writing correct threaded code is hard, and if > we make it too difficult, it will have *very* little effect on the > userbase, since very few people will be able to write code for FreeBSD. I'm trying to facilitate a POSIX compliant interface providing all the features that POSIX and SSv2 pthreads provide. I'm not advocating adding all sorts of non-portable interfaces. We may end up playing games like Solaris does with PTHREAD_SCOPE_PROCESS threads being created and bound to 'kernel schedulable entities', though, but I don't see this being a problem. > Highly motivated individuals will be able to write code, but if we come > up with a very complicated design that requires lots of extra work, very > few people will be able to use the new threaded features of FreeBSD. > > My plea is to keep is simple. KISS rules here, and although flexibility > is a grand goal, KISS should always win out. I agree, but I don't see SA plus ability to bind threads to KSEs as being all that complicated. I like SA because it makes the threads library much easier to implement than it would be with an approach like LinuxThreads where there would be all sorts of locking problems. Think of all the work that libc_r currently has to do to prevent blocking in the kernel. SA would eliminate that. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 3 10:29:36 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2A2BE14F04 for ; Wed, 3 Nov 1999 10:29:30 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA14545 for ; Wed, 3 Nov 1999 19:29:19 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA88397 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 19:29:19 +0100 (MET) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 4B1A214D0B for ; Wed, 3 Nov 1999 10:08:39 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p27-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.156]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id DAA18650; Thu, 4 Nov 1999 03:06:50 +0900 (JST) Message-ID: <38207424.9AAA48E8@newsguy.com> Date: Thu, 04 Nov 1999 02:43:00 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Wes Peters Cc: freebsd-arch@freebsd.org Subject: Re: Extended partitions References: <381F19C0.577FFA0D@softweyr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters wrote: > > Yes? No? Maybe? If there is sufficient interest, I'll explain to him how > to CVSup and get him rolling on it ASAP. This would be nice to have for > 4.0 release. Yes, it would be interesting, if the trade-off is acceptable. There *will* be a trade-off, because this affects boot[0-2] (and loader), and these programs run on a tight space. You might as well point him to Robert Nordier (rnordier), if he chooses to accept this mission. [insert favorite mission impossible disclaimer here] -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org What y'all wanna do? Wanna be hackers? Code crackers? Slackers Wastin' time with all the chatroom yakkers? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 3 13: 3:34 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 36AA114BD8 for ; Wed, 3 Nov 1999 13:03:20 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA16611 for ; Wed, 3 Nov 1999 22:03:03 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA89294 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 22:03:03 +0100 (MET) Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 6F99C14DC6 for ; Wed, 3 Nov 1999 13:02:19 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id VAA47172; Wed, 3 Nov 1999 21:02:29 GMT (envelope-from dfr@nlsystems.com) Date: Wed, 3 Nov 1999 21:02:29 +0000 (GMT) From: Doug Rabson To: "Richard Seaman, Jr." Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) In-Reply-To: <19991103074651.E5715@tar.com> 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 Wed, 3 Nov 1999, Richard Seaman, Jr. wrote: > As a 4) can I suggest: > > Debugger support for threads. I already have this (for the existing uthreads). It got broken slightly by the signal changes but it shouldn't be hard to fix. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 3 13:11:12 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 5497214CE0 for ; Wed, 3 Nov 1999 13:11:07 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA16740 for ; Wed, 3 Nov 1999 22:11:03 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA89368 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 22:11:03 +0100 (MET) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 8BB8314C83; Wed, 3 Nov 1999 13:10:50 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40325>; Thu, 4 Nov 1999 08:05:18 +1100 Content-return: prohibited Date: Thu, 4 Nov 1999 08:10:43 +1100 From: Peter Jeremy Subject: Pageable kernels (was Re: diskless boot roadmap) In-reply-to: <99110304555400.19188@nomad.dataplex.net> To: Richard Wackerbarth Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Nov4.080518est.40325@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <99Nov3.160403est.40416@border.alcanet.com.au> <199911030515.VAA02306@dingo.cdrom.com> <99Nov3.163119est.40376@border.alcanet.com.au> <99110304555400.19188@nomad.dataplex.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [This is heading more towards -arch than -current] On 1999-Nov-03 21:53:07 +1100, Richard Wackerbarth wrote: >> How much of the probe code can we move into userland? >Or alternately, transient kernel memory. Use it, then lose it. IMHO, there are some items (like the PNP ID tables) that really belong in a user-editable file, rather than the kernel source. This file could then be read by /boot/loader (and maybe a runtime daemon similar to pccardd). And taking the idea of transient kernel memory a bit further: How about supporting paging within the kernel? At least for text space, this would seem to be a fairly simple matter of tagging functions as pageable (eg add '__attribute__((section("text_pageable")))' to the function declaration), and treating that section of KVM the same way as user text space (though probably with a higher preference for being resident and a higher priority for paging in). Paging data may be a bit trickier, but would seem to be amenable to a mixture of variable attributes and a new `pageable' flag for kernel malloc. Initialisation code is an obvious candidate for paging, but I suspect that everything except interrupt handlers, the paging code and device drivers associated with the paging devices could be made pageable. In fact, the above all sounds so obvious and simple that I wonder if I'm missing something... Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 3 13:42:30 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id BDB79150CA for ; Wed, 3 Nov 1999 13:42:26 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA17070 for ; Wed, 3 Nov 1999 22:42:20 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA89585 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 22:42:19 +0100 (MET) Received: from rah.star-gate.com (216-200-29-190.snj0.flashcom.net [216.200.29.194]) by hub.freebsd.org (Postfix) with ESMTP id D6A3F150CA for ; Wed, 3 Nov 1999 13:41:47 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.3/8.8.8) with ESMTP id NAA39580 for ; Wed, 3 Nov 1999 13:40:06 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199911032140.NAA39580@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) In-reply-to: Your message of "Wed, 03 Nov 1999 21:02:29 GMT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Nov 1999 13:40:06 -0800 From: Amancio Hasty Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Wed, 3 Nov 1999, Richard Seaman, Jr. wrote: > > > As a 4) can I suggest: > > > > Debugger support for threads. > > I already have this (for the existing uthreads). It got broken slightly by > the signal changes but it shouldn't be hard to fix. > Most cool and is the debugger support for gdb? -- Amancio Hasty hasty@rah.star-gate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 3 16:33:33 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 7D3EA1506A for ; Wed, 3 Nov 1999 16:33:06 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id BAA18608 for ; Thu, 4 Nov 1999 01:32:45 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA90402 for freebsd-arch@freebsd.org; Thu, 4 Nov 1999 01:32:40 +0100 (MET) Received: by hub.freebsd.org (Postfix, from userid 758) id EFC2115132; Wed, 3 Nov 1999 16:32:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id CEDFE1CD776; Wed, 3 Nov 1999 16:32:23 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Wed, 3 Nov 1999 16:32:23 -0800 (PST) From: Kris Kennaway To: Amancio Hasty Cc: freebsd-arch@freebsd.org Subject: Re: Solaris terminology In-Reply-To: <199911030800.AAA33669@rah.star-gate.com> 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 Wed, 3 Nov 1999, Amancio Hasty wrote: > BTW: SGI is supposed to be working on Linux to make it more scalable across > multiple processors . The figure that I heard is that they were aiming for 100 > processors or so . > > Since SGIs work is supposed to be "open-source" perhaps someone can > dig up what SGI is up to ... I don't believe SGI has actually released any code yet at all (except for OpenVault), despite their much-vaunted "commitment to open source". Kris ---- Cthulhu for President! For when you're tired of choosing the _lesser_ of two evils.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 4 2:33:19 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2337814D52 for ; Thu, 4 Nov 1999 02:33:15 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id LAA24769 for ; Thu, 4 Nov 1999 11:33:14 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA92026 for freebsd-arch@freebsd.org; Thu, 4 Nov 1999 11:33:14 +0100 (MET) Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 7F74A14F23 for ; Thu, 4 Nov 1999 02:31:38 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id KAA33543; Thu, 4 Nov 1999 10:30:02 GMT (envelope-from dfr@nlsystems.com) Date: Thu, 4 Nov 1999 10:30:02 +0000 (GMT) From: Doug Rabson To: Amancio Hasty Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) In-Reply-To: <199911032140.NAA39580@rah.star-gate.com> 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 Wed, 3 Nov 1999, Amancio Hasty wrote: > > On Wed, 3 Nov 1999, Richard Seaman, Jr. wrote: > > > > > As a 4) can I suggest: > > > > > > Debugger support for threads. > > > > I already have this (for the existing uthreads). It got broken slightly by > > the signal changes but it shouldn't be hard to fix. > > > > Most cool and is the debugger support for gdb? Yes it is. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 4 10: 6:47 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C419614DF6 for ; Thu, 4 Nov 1999 10:06:43 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA02593 for ; Thu, 4 Nov 1999 19:06:40 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA94296 for freebsd-arch@freebsd.org; Thu, 4 Nov 1999 19:06:39 +0100 (MET) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id DFC6C151C2 for ; Thu, 4 Nov 1999 10:04:59 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id LAA27155; Thu, 4 Nov 1999 11:04:20 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpdAAA_QaaX0; Thu Nov 4 11:04:10 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id LAA18253; Thu, 4 Nov 1999 11:04:17 -0700 (MST) From: Terry Lambert Message-Id: <199911041804.LAA18253@usr06.primenet.com> Subject: Re: Threads goals version III To: julian@whistle.com (Julian Elischer) Date: Thu, 4 Nov 1999 18:04:17 +0000 (GMT) Cc: freebsd-arch@freebsd.org In-Reply-To: from "Julian Elischer" at Oct 31, 99 07:09:04 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have been extermely busy at work, so I have not had time to contribute tothis discussion until now. I actually got up early today so I could do so... > ---Possible system design goals of system threads support -- > --- Note just becasue something is in this list doesn't mean that > it will be done, just that it's going o be carried forward to > further discussion. > -------------------------------------------------------------- I think there are some first principles missing here; the initial design goals of threads, when they were first invented, were: 1) A means of allowing programmers to build procedural soloutions instead of state machines. This is really a programmer convenience, for programmers who know how to write linear code, but don't know how to do finite state automata, to enable them to write code to solve certain classes of problems that they would not otherwise be able to solve. While I agree that it's nice that these people can be productive members of society without having to ask "would you like fries with that?", it's not really the overriding goal, it's just a side effect (a desirable one, and one that probably shouldn't be avoided in order to solve the other problems threads were designed to solve). Let's call this "allowing complex problems to be solved by procedural decomposition at a slightly higher cost than we'd have solving them by Carnot decomposition". 2) Something "lighter weight" than a several processes written to cooperatively solve the same problem. This implies a lot of things, but the top ones are: o Lower context switch overhead o Better utilization of quantum o Cheaper inter-context communication mechanisms o A way to reduce the number of processes that are taking up per-process resources on the system o A way to increase outstanding I/O and other high latency operations' concurrency I think we can agree that user space threads have lower context switch overhead that kernel space threads. I think we can agree that a user space threads scheduler context switch has a better quantum utilization than a blocking kernel thread, which gives up its quantum when it blocks. I think we can agree that user/kernel is irrelevant, so long as the address space is shared, in providing cheaper inter-context communications. I think we can agree that, when we talked about number of processes taking up per-process resources, we were really talking about kernel scheduling contexts, and so user space threads better achieves this goal than kernel space threads; by the same token, however, the resources which we are concerned about are less expensive than they used to be, and it may be time to reconsider the tradeoff we were trying to make. I think we can agree that, so long as the I/O and other high latency operations can be scheduled to occur, it doesn't matter that, while they are pending, something else is running, so that user space call-conversion (sync call = async call + user space threads context switch) is probably _more_ efficient than using a kernel thread and blocking it, and then using the kernel scheduler to schedule another thread (or process). So why not implement user space threads? Somewhere along the way, some additional factors have cropped up; these were not the initial intended use of threads, but they have been used to solve the problems associated with them, and it's generally a good design principle to not introduce new interfaces when you have perfectly good interfaces that can be used to solve the problem. The new factors are: 1) SMP scalability In order to scale a threaded process with the number of processors that a system has available, it's necessary to allow multiple processors into the same process context. This is partially a scheduler issue in the kernel, and partially a user space stack issue. The traditional answer to this was to introduce all sorts of N:M mapping schemes between multiple user space (N) and kernel space (M) threads and processors (P), where (N >= M) and (M <= P). 2) Long latency interleave of non-asynchronous system calls using heavy-weight kernel context switches in order to achieve the interleave. In laymans terms, we set (M > P) in order to allow (M) outstanding blocking calls to exist from the user space process for (M) threads. 3) Lazy-binding of kernel resources In order to lazy-bind kernel resources, such that the number of threads could be fluid, and so that we could not have to think ahead of time how many potential blocking calls we would need, we allocate a minimum of 2 kernel threads initially, and allocate more as blocking of user space calls into the kernel occur. To achieve this (2 <= M <= P + 1). The extra kernel thread is used to signal a user space scheduler thread to create more kernel threads, if desired, since all kernel threads bound to user space calls in progress are currently blocked. This is an anti-starvation strategy, which keeps runnable user space threads from being starved of kernel threads to utilized for blocking call contexts. Note: This is the current preverred Solaris model. 4) Abuse of kernel threads in order to compete as N kernel schedulable entities with respect to other processes in the system This is a dodge to avoid supporting or implementing scheduler callses for the class of problems that really need scheduler classes, in the hopes that a certain unfair competition ratio "will be enough". Of these, SMP scaling is the only truly compelling argument. Long latency interleave is not a good argument; there are obvious and significantly lighter weight methods of achieving this goal, starting with POSIX async I/O. While it's obviously a half-done hack that only covers things that were "important" at the time they were defining it, it at least points to a workable lower overhead alternative. The lazy-binding of kernel resources makes a couple of assumptions: o The implementation will be via kernel threads o Because the implementation will be via kernel threads, there is a need to minimize the impact of the way it will be implemented St. Thomas Aquinas and Douglas Hofsteader would be very pleased about this circular argument justifying the existance of its own topic. 8-). We can throw the abuse argument out. POSIX supplies mechanisms for dealing with this, including the idea of pluggable scheduling classes, and FreeBSD already supports many of these. This leaves us with: o Allowing complex problems to be solved by procedural decomposition o Lower context switch overhead o Better utilization of quantum o Cheaper inter-context communication mechanisms o A way to reduce the number of processes that are taking up per-process resources on the system o A way to increase outstanding I/O and other high latency operations' concurrency o SMP scalability As the true goals. Julian has asked me several times to write up my threading model; he's seen it on a white board, and I've been able to address all of his concerns regarding it there. I'll write that up for the implemetnation phase of the discussion, as my proposal for an implementation to address all of the stated design goals. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 4 14: 0:20 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2711814C2B for ; Thu, 4 Nov 1999 14:00:17 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA04887 for ; Thu, 4 Nov 1999 22:57:32 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA95137 for freebsd-arch@freebsd.org; Thu, 4 Nov 1999 22:57:31 +0100 (MET) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id B978D14C2B for ; Thu, 4 Nov 1999 13:57:05 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40325>; Fri, 5 Nov 1999 08:51:19 +1100 Content-return: prohibited Date: Fri, 5 Nov 1999 08:56:49 +1100 From: Peter Jeremy Subject: Re: Threads goals version III In-reply-to: <199911041804.LAA18253@usr06.primenet.com> To: freebsd-arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Nov5.085119est.40325@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <199911041804.LAA18253@usr06.primenet.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Nov-05 05:04:17 +1100, Terry Lambert wrote: >1) A means of allowing programmers to build procedural > soloutions instead of state machines. > > This is really a programmer convenience, for programmers > who know how to write linear code, but don't know how to > do finite state automata, I think that's being a bit unfair. One problem with FSA's is that following their internal logic can sometimes be substantially more difficult than following an equivalent linear control flow. This makes than more difficult to write and check - and increases the maintenance costs. >1) SMP scalability IMHO, this is going to rise in importance over time - and probably become the predominant reason for writing threaded code. It's becoming more and more difficult to make single processors faster, so fast machines will increasingly rely on multiple processors. >Julian has asked me several times to write up my threading model; >he's seen it on a white board, and I've been able to address all >of his concerns regarding it there. The rest of us would also like to see it. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 4 14:56:40 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 60AE915164 for ; Thu, 4 Nov 1999 14:56:37 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA05485 for ; Thu, 4 Nov 1999 23:54:55 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA95404 for freebsd-arch@freebsd.org; Thu, 4 Nov 1999 23:54:55 +0100 (MET) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 6AA6B1570C for ; Thu, 4 Nov 1999 14:50:55 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id PAA23873; Thu, 4 Nov 1999 15:50:22 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp02.primenet.com, id smtpd023797; Thu Nov 4 15:50:10 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id PAA19151; Thu, 4 Nov 1999 15:50:09 -0700 (MST) From: Terry Lambert Message-Id: <199911042250.PAA19151@usr07.primenet.com> Subject: Re: Threads goals version III To: peter.jeremy@alcatel.com.au Date: Thu, 4 Nov 1999 22:50:07 +0000 (GMT) Cc: freebsd-arch@freebsd.org In-Reply-To: <99Nov5.085119est.40325@border.alcanet.com.au> from "Peter Jeremy" at Nov 5, 99 08:56:49 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On 1999-Nov-05 05:04:17 +1100, Terry Lambert wrote: > >1) A means of allowing programmers to build procedural > > soloutions instead of state machines. > > > > This is really a programmer convenience, for programmers > > who know how to write linear code, but don't know how to > > do finite state automata, > > I think that's being a bit unfair. > > One problem with FSA's is that following their internal logic can > sometimes be substantially more difficult than following an equivalent > linear control flow. This makes than more difficult to write and > check - and increases the maintenance costs. I won't bore you with cries of "branch path validation"; I will only point out that any code can be made difficult, or easy, to maintain using literate programming techniques and documentation that covers the actual implementation's design. An FSA is only as hard to follow as its documentation is poor. FSA's also have the advantage of usually being more efficient than multiple threads with explicit IPC and synchronization points, since they don't have to stall execution during them. Nevertheless, it is sometimes as useful to implement using a threaded execution model instead of an FSA, either because you have junior level people doing the implementation, or you expect to have junior level people doing maintenance (in either case, it's _not_ acceptable to do because you "choose not to document" or your "design does not match the code"; either of these will prevent you from doing adequate testing). > >1) SMP scalability > > IMHO, this is going to rise in importance over time - and probably > become the predominant reason for writing threaded code. It's > becoming more and more difficult to make single processors faster, > so fast machines will increasingly rely on multiple processors. I agree. That's why I didn't throw out at least kernel cooperation of some kind; it's just a question of where you place the line in order to get multiple CPU's in user space at the same time. In terms of meeting the goals of having threads in the first place, kernel threads vs. kernel call contexts are an issue to address in terms of implementation strategies. At the same time, you could argue about cache busting, locality of reference, interprocessor contention, and all of the other issues related to enabling either kernel threads or multiple CPU's in user space in the same process in something other than a work-to-do design for a threaded program. As I said: this is an issue of implementation strategy, and I'm happy to keep it seperate from the goals list. 8-). > >Julian has asked me several times to write up my threading model; > >he's seen it on a white board, and I've been able to address all > >of his concerns regarding it there. > > The rest of us would also like to see it. > > Peter I'm working, I'm working. I'm in the middle of a Y2K audit of a network operations center. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 4 14:57:35 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id BC48C15164 for ; Thu, 4 Nov 1999 14:57:31 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA05521 for ; Thu, 4 Nov 1999 23:56:14 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA95421 for freebsd-arch@freebsd.org; Thu, 4 Nov 1999 23:56:14 +0100 (MET) Received: from plunger.gdeb.com (plunger.gdeb.com [153.11.11.3]) by hub.freebsd.org (Postfix) with ESMTP id 9E2641571D for ; Thu, 4 Nov 1999 14:50:58 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from orion.caen.gdeb.com ([153.11.109.11]) by plunger.gdeb.com with ESMTP id RAA16015; Thu, 4 Nov 1999 17:46:32 -0500 (EST) Received: from vigrid.com (clcrtr [153.11.109.129]) by orion.caen.gdeb.com (8.9.3/8.9.3) with ESMTP id RAA48020; Thu, 4 Nov 1999 17:48:43 -0500 (EST) (envelope-from eischen@vigrid.com) Message-ID: <38220D4B.9BEAFCDB@vigrid.com> Date: Thu, 04 Nov 1999 17:48:43 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.51 [en] (X11; U; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads goals version III References: <199911041804.LAA18253@usr06.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > 4) Abuse of kernel threads in order to compete as N kernel > schedulable entities with respect to other processes in > the system > > This is a dodge to avoid supporting or implementing > scheduler callses for the class of problems that really > need scheduler classes, in the hopes that a certain > unfair competition ratio "will be enough". 4a) Use of kernel threads to compete in different scheduler classes? We have a MT application under Solaris with a few threads bound to LWPs and placed in the real-time scheduler class. These threads are carefully crafted to not chew up the CPU, but to respond in a timely manner to events. The rest of the threads in the application are not in the real-time class (and we don't want them to be) I think that what you're implying in 4, is that an application should place itself in the proper scheduling class/priority to "achieve unfair competition". My concern is that we not restrict the kernel scheduling class to be at the process level, but we allow for fine grained control of the threads within a process. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 4 15:17:52 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 51F1C14D7C for ; Thu, 4 Nov 1999 15:17:41 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA05886 for ; Fri, 5 Nov 1999 00:17:40 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA95525 for freebsd-arch@freebsd.org; Fri, 5 Nov 1999 00:17:39 +0100 (MET) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id CE36214D7C for ; Thu, 4 Nov 1999 15:17:01 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id QAA29337; Thu, 4 Nov 1999 16:15:30 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp01.primenet.com, id smtpdAAAuxa4R4; Thu Nov 4 16:14:49 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id QAA20206; Thu, 4 Nov 1999 16:14:22 -0700 (MST) From: Terry Lambert Message-Id: <199911042314.QAA20206@usr07.primenet.com> Subject: Re: Threads goals version III To: eischen@vigrid.com (Daniel M. Eischen) Date: Thu, 4 Nov 1999 23:14:21 +0000 (GMT) Cc: tlambert@primenet.com, julian@whistle.com, freebsd-arch@freebsd.org In-Reply-To: <38220D4B.9BEAFCDB@vigrid.com> from "Daniel M. Eischen" at Nov 4, 99 05:48:43 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 4) Abuse of kernel threads in order to compete as N kernel > > schedulable entities with respect to other processes in > > the system > > > > This is a dodge to avoid supporting or implementing > > scheduler callses for the class of problems that really > > need scheduler classes, in the hopes that a certain > > unfair competition ratio "will be enough". > > 4a) Use of kernel threads to compete in different scheduler > classes? > > We have a MT application under Solaris with a few threads bound > to LWPs and placed in the real-time scheduler class. These threads > are carefully crafted to not chew up the CPU, but to respond in a > timely manner to events. The rest of the threads in the application > are not in the real-time class (and we don't want them to be) > > I think that what you're implying in 4, is that an application > should place itself in the proper scheduling class/priority to > "achieve unfair competition". My concern is that we not restrict > the kernel scheduling class to be at the process level, but we > allow for fine grained control of the threads within a process. This is an interesting application, however FreeBSD interrupt processing is far from deterministic enough to deal with this issue properly, and moving interrupt processing into kernel threads, which I agree may deal with the SPL issue, will only further damage determinism. One could argue that the program should be using a hybrid scheduling class in the kernel in order to achieve this effect, rather than having to have the idea that you would want to schedule seperate kernel schedulable entities within one program. One of the problems with the Solaris model, overall, is that the term "LWP" is heavily overloaded in Sun-originated literature. For example, in SunOS 4.x, ther was a "liblwp", which was a call conversion user space threads scheduler that did not support SMP scaling or the concept of kernel threads (see the University of Washington paper "User space threads and SPARC Register Windows", from which the original 4.x liblwp implementation was derived). The term I use, KSE (for "Kernel Schedulable Entity"), while more technically correct a description, is also bad, since it has only a little use in the literature. When you say "LWP" in post 4.x Solaris, you're really saying what common usage calls "a kernel thread". This is similarly a bad term, since it implies a whole lot of implementation assuptions that I'm really not prepared to buy into before the goals of "why FreeBSD needs threads" are defined beyond "Linux has them" or "POSIX programmers use them". I would like to see us seperate the idea of threads vs. kernel scheduling. Ideally, there would be very few modifications of the kernel scheduler necessary to support fully threaded, multiple CPU reentrant user space code. The primary ones that I foresee are: o Per CPU run queues o Per process CPU utilization bitmaps (this is possibly a premature optimization, in that it may be acceptable for the process of asking to get on the scheduler queue for additional CPUs could be permitted to be expensive) o A scheduler queue migration facility for gross load balancing over time (statistical, per similar algorithms use in ATM, perhaps). o Seperation of "struct proc" and "struct thread", with the latter primarily being a pointer to the former, a pointer to a kernel stack, a register set, sleep queue context management, a pointer to a user space call completion context, and a linked list by which it could be hung off the proc struct (for things like _exit processing and signals, etc.). Caveat: this is implementation space, and I'd like to get my thoughts into a coherent whole, while allowing others to do the same, so that we can present our ideas around the same time, and the best ideas from everyone's models can make it into the final design. One idea that I would like to _omit_ from the final design is "kernel threads are required for SMP scalability and kernel scheduler differentiation"; it's just not true. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 4 16:51:59 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id DD07A1511A for ; Thu, 4 Nov 1999 16:51:41 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id BAA06636 for ; Fri, 5 Nov 1999 01:51:38 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA95938 for freebsd-arch@freebsd.org; Fri, 5 Nov 1999 01:51:37 +0100 (MET) Received: from rah.star-gate.com (216-200-29-190.snj0.flashcom.net [216.200.29.194]) by hub.freebsd.org (Postfix) with ESMTP id 16FEA157AD for ; Thu, 4 Nov 1999 16:49:44 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.3/8.8.8) with ESMTP id QAA49642; Thu, 4 Nov 1999 16:48:33 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199911050048.QAA49642@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert Cc: eischen@vigrid.com (Daniel M. Eischen), julian@whistle.com, freebsd-arch@freebsd.org Subject: Re: Threads goals version III In-reply-to: Your message of "Thu, 04 Nov 1999 23:14:21 GMT." <199911042314.QAA20206@usr07.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Nov 1999 16:48:32 -0800 From: Amancio Hasty Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > One could argue that the program should be using a hybrid scheduling > class in the kernel in order to achieve this effect, rather than > having to have the idea that you would want to schedule seperate > kernel schedulable entities within one program. How to you propose to handle priorieties for different "thread thingies" --- "thread thingies" being a yet to be defined thread implementation. What I am think is that for whatever reason there are applications which want threads to be running at different priorities for instance "Kaffe" wants or needs threads running at different priorities. *Not interested in arguing about whether Kaffe's thread management is broken or not *. -- Amancio Hasty hasty@rah.star-gate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 4 17:21:30 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 734CC151DC for ; Thu, 4 Nov 1999 17:21:21 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id CAA07068 for ; Fri, 5 Nov 1999 02:21:00 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA96152 for freebsd-arch@freebsd.org; Fri, 5 Nov 1999 02:21:00 +0100 (MET) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id C175915869 for ; Thu, 4 Nov 1999 17:18:29 -0800 (PST) (envelope-from rcarter@chomsky.Pinyon.ORG) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id SAA14762; Thu, 4 Nov 1999 18:17:20 -0700 (MST) Received: from ip-83-024.prc.primenet.com(207.218.83.24), claiming to be "chomsky.pinyon.org" via SMTP by smtp01.primenet.com, id smtpdAAAnHaGvC; Thu Nov 4 18:17:11 1999 Received: from chomsky.Pinyon.ORG (localhost [127.0.0.1]) by chomsky.pinyon.org (Postfix) with ESMTP id CE5AD4D; Thu, 4 Nov 1999 18:16:23 -0700 (MST) X-Mailer: exmh version 2.1.0 09/18/1999 To: Amancio Hasty Cc: Terry Lambert , eischen@vigrid.com (Daniel M. Eischen), julian@whistle.com, freebsd-arch@freebsd.org, rcarter@pinyon.org Subject: Re: Threads goals version III In-Reply-To: Message from Amancio Hasty of "Thu, 04 Nov 1999 16:48:32 PST." <199911050048.QAA49642@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Nov 1999 18:16:23 -0700 From: "Russell L. Carter" Message-Id: <19991105011623.CE5AD4D@chomsky.pinyon.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG %> One could argue that the program should be using a hybrid scheduling %> class in the kernel in order to achieve this effect, rather than %> having to have the idea that you would want to schedule seperate %> kernel schedulable entities within one program. % %How to you propose to handle priorieties for different %"thread thingies" --- "thread thingies" being a yet to %be defined thread implementation. % One uses pthread_*sched* routines to modify scheduling attributes for individual threads. Whether or not those threads can get process or system scope, as in the spec, or just process scope, that is the question. If I groked Terry's first missive then the process should first set scheduling attributes via sched_setscheduler, if it needs something other than SCHED_OTHER (default per process scheduling). I'm still studying whether or not this is good enough; i.e., can individual threads in a process with a SCHED_FIFO or SCHED_RR policies meet QoS goals, and does it provide the flexibility needed by an application structured as Daniel's is. Russell To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 4 18: 7:38 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 8C80114D6A for ; Thu, 4 Nov 1999 18:07:27 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA07540 for ; Fri, 5 Nov 1999 03:07:25 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA96420 for freebsd-arch@freebsd.org; Fri, 5 Nov 1999 03:07:24 +0100 (MET) Received: from rah.star-gate.com (216-200-29-190.snj0.flashcom.net [216.200.29.194]) by hub.freebsd.org (Postfix) with ESMTP id 0C11E14D6A for ; Thu, 4 Nov 1999 18:07:12 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.3/8.8.8) with ESMTP id SAA50331; Thu, 4 Nov 1999 18:04:25 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199911050204.SAA50331@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Russell L. Carter" Cc: Terry Lambert , eischen@vigrid.com (Daniel M. Eischen), julian@whistle.com, freebsd-arch@freebsd.org, rcarter@pinyon.org Subject: Re: Threads goals version III In-reply-to: Your message of "Thu, 04 Nov 1999 18:16:23 MST." <19991105011623.CE5AD4D@chomsky.pinyon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Nov 1999 18:04:25 -0800 From: Amancio Hasty Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > %> One could argue that the program should be using a hybrid scheduling > %> class in the kernel in order to achieve this effect, rather than > %> having to have the idea that you would want to schedule seperate > %> kernel schedulable entities within one program. > % > %How to you propose to handle priorieties for different > %"thread thingies" --- "thread thingies" being a yet to > %be defined thread implementation. > % > > One uses pthread_*sched* routines to modify scheduling > attributes for individual threads. Whether or not those threads > can get process or system scope, as in the spec, or just process > scope, that is the question. > > If I groked Terry's first missive then the process should first > set scheduling attributes via sched_setscheduler, if it needs > something other than SCHED_OTHER (default per process scheduling). > I'm still studying whether or not this is good enough; i.e., can > individual threads in a process with a SCHED_FIFO or SCHED_RR > policies meet QoS goals, and does it provide the flexibility > needed by an application structured as Daniel's is. > Well, we slowly edging to a possible solution we just to need to investigate what the "scheduling" implementation is going to be for most likely it will affect the kernel scheduler . > -- Amancio Hasty hasty@rah.star-gate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 4 18:37:26 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 4B26015753 for ; Thu, 4 Nov 1999 18:37:21 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA07769 for ; Fri, 5 Nov 1999 03:35:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA96564 for freebsd-arch@freebsd.org; Fri, 5 Nov 1999 03:35:36 +0100 (MET) Received: by hub.freebsd.org (Postfix, from userid 758) id D340C15753; Thu, 4 Nov 1999 18:35:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id C38391CD7FC for ; Thu, 4 Nov 1999 18:35:30 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Thu, 4 Nov 1999 18:35:30 -0800 (PST) From: Kris Kennaway To: arch@freebsd.org Subject: Scheduler Activations refs 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 Some more references to work by Anderson et al on Scheduler Activations: Adding Scheduler Activations to Mach 3.0 ftp://ftp.cs.washington.edu/tr/1992/08/UW-CSE-92-08-03.PS.Z User-Level Threads and Interprocess Communication ftp://ftp.cs.washington.edu/tr/1993/02/UW-CSE-93-02-03.PS.Z Tools and Techniques for Building Fast Portable Threads Packages ftp://ftp.cs.washington.edu/tr/1993/05/UW-CSE-93-05-06.PS.Z Other thread implementation papers: Efficient Support for Fine-Grain Parallelism ftp://ftp.cs.arizona.edu/reports/1993/TR93-13a.ps Performance Experiments for the Filaments Package ftp://ftp.cs.arizona.edu/reports/1993/TR93-26.ps Space-efficient Scheduling for Parallel, Multithreaded Computations http://reports-archive.adm.cs.cmu.edu/anon/1999/CMU-CS-99-119.ps Hope someone else finds these interesting.. Kris ---- Cthulhu for President! For when you're tired of choosing the _lesser_ of two evils.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 4 19:11: 2 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3777114BF4 for ; Thu, 4 Nov 1999 19:10:59 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA08529 for ; Fri, 5 Nov 1999 04:10:42 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA96778 for freebsd-arch@freebsd.org; Fri, 5 Nov 1999 04:10:41 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 0EBE315858 for ; Thu, 4 Nov 1999 19:08:59 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt9.pcnet.net [206.105.29.83]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id WAA29629; Thu, 4 Nov 1999 22:03:52 -0500 (EST) Message-ID: <38224942.6447A8B2@vigrid.com> Date: Thu, 04 Nov 1999 22:04:34 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: rcarter@chomsky.Pinyon.ORG Cc: Amancio Hasty , Terry Lambert , julian@whistle.com, freebsd-arch@freebsd.org Subject: Re: Threads goals version III References: <19991105011623.CE5AD4D@chomsky.pinyon.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Russell L. Carter" wrote: > > %> One could argue that the program should be using a hybrid scheduling > %> class in the kernel in order to achieve this effect, rather than > %> having to have the idea that you would want to schedule seperate > %> kernel schedulable entities within one program. > % > %How to you propose to handle priorieties for different > %"thread thingies" --- "thread thingies" being a yet to > %be defined thread implementation. > % > > One uses pthread_*sched* routines to modify scheduling > attributes for individual threads. Whether or not those threads > can get process or system scope, as in the spec, or just process > scope, that is the question. > > If I groked Terry's first missive then the process should first > set scheduling attributes via sched_setscheduler, if it needs > something other than SCHED_OTHER (default per process scheduling). > I'm still studying whether or not this is good enough; i.e., can > individual threads in a process with a SCHED_FIFO or SCHED_RR > policies meet QoS goals, and does it provide the flexibility > needed by an application structured as Daniel's is. I don't think it does. I think under Terry's scheme, it wouldn't be possible to bind a thread to a KSE and place it in a different scheduler class. It would still be possible to run [user] threads in different scheduler classes without being bound to a KSE, but this wouldn't reserve a quantum in which the threads could execute. So if the application on the whole was at or near it's process limits, the threads in the real-time (or some other than the default) scheduler class wouldn't be able to run. You could make allowances for this situation and manage accounting differently for a process running under multiple scheduling classes, but it still seems simpler to allow (with correct privileges) system scope threads to be bound to KSEs with their own quantum. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 5 7: 9:46 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 066C21505E for ; Fri, 5 Nov 1999 07:09:38 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id QAA19480 for ; Fri, 5 Nov 1999 16:09:33 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA99527 for freebsd-arch@freebsd.org; Fri, 5 Nov 1999 16:09:32 +0100 (MET) Received: from bachue.usc.unal.edu.co (bachue.usc.unal.edu.co [168.176.3.20]) by hub.freebsd.org (Postfix) with ESMTP id 505761505E for ; Fri, 5 Nov 1999 07:09:20 -0800 (PST) (envelope-from pfgiffun@bachue.usc.unal.edu.co) Received: from bachue.usc.unal.edu.co ([168.176.3.58]) by bachue.usc.unal.edu.co (Netscape Messaging Server 3.6) with ESMTP id AAA5786 for ; Fri, 5 Nov 1999 10:10:30 -0500 Message-ID: <3822F55C.506F5E48@bachue.usc.unal.edu.co> Date: Fri, 05 Nov 1999 10:18:52 -0500 From: "Pedro Fernando Giffuni" Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: arch@freebsd.org Subject: Re: Scheduler Activations refs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This URL from Microsoft Research seems interesting: http://www.research.microsoft.com/~mbj/papers.html enjoy, Pedro. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 5 12: 6:30 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 4FFC014D90 for ; Fri, 5 Nov 1999 12:06:18 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA23299 for ; Fri, 5 Nov 1999 21:05:12 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA00920 for freebsd-arch@freebsd.org; Fri, 5 Nov 1999 21:05:11 +0100 (MET) Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 4F0F115227 for ; Fri, 5 Nov 1999 12:04:14 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id OAA15995 for ; Fri, 5 Nov 1999 14:59:40 -0500 (EST) Reply-To: Randell Jesup To: arch@freebsd.org Subject: Re: FSM's References: <3822F55C.506F5E48@bachue.usc.unal.edu.co> From: Randell Jesup Date: 05 Nov 1999 16:00:34 +0000 In-Reply-To: "Pedro Fernando Giffuni"'s message of "Fri, 05 Nov 1999 10:18:52 -0500" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Jeremy writes: >>1) A means of allowing programmers to build procedural >> soloutions instead of state machines. >> >> This is really a programmer convenience, for programmers >> who know how to write linear code, but don't know how to >> do finite state automata, > >I think that's being a bit unfair. > >One problem with FSA's is that following their internal logic can >sometimes be substantially more difficult than following an equivalent >linear control flow. This makes than more difficult to write and >check - and increases the maintenance costs. FSM's also have the implicit assumption that inputs can be handled in order of reception, and in a timely fashion. If some inputs need quicker responses than the time to handle other inputs allows, FSM's have a problem. This is one reason why threaded programs/OS's can have a very snappy UI response 'feel' compared to single-threaded - the UI response can run on a different thread than handling of the UI-invoked events. This isn't even considering the issues of (long) blocking system calls, which make it more of an issue. FSM's where there are a number of loosely related sets of states can be very confusing as well. Threads mean you have to worry about synchronization and locking. Oh well; every technique has plusses and minuses. >>1) SMP scalability > >IMHO, this is going to rise in importance over time - and probably >become the predominant reason for writing threaded code. It's >becoming more and more difficult to make single processors faster, >so fast machines will increasingly rely on multiple processors. This hasn't happened yet, though it's been predicted for a decade or more - but I agree, it has to happen eventually. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 5 13: 8:37 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3415314D64 for ; Fri, 5 Nov 1999 13:08:29 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA24188 for ; Fri, 5 Nov 1999 22:07:20 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA01159 for freebsd-arch@freebsd.org; Fri, 5 Nov 1999 22:07:20 +0100 (MET) Received: from rah.star-gate.com (216-200-29-190.snj0.flashcom.net [216.200.29.194]) by hub.freebsd.org (Postfix) with ESMTP id 8DBEE14D64 for ; Fri, 5 Nov 1999 13:07:03 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.3/8.8.8) with ESMTP id NAA57850; Fri, 5 Nov 1999 13:05:55 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199911052105.NAA57850@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Randell Jesup Cc: arch@freebsd.org Subject: Re: FSM's In-reply-to: Your message of "05 Nov 1999 16:00:34 GMT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Nov 1999 13:05:55 -0800 From: Amancio Hasty Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Peter Jeremy writes: > >>1) A means of allowing programmers to build procedural > >> soloutions instead of state machines. > >> > >> This is really a programmer convenience, for programmers > >> who know how to write linear code, but don't know how to > >> do finite state automata, > > > >I think that's being a bit unfair. > > > >One problem with FSA's is that following their internal logic can > >sometimes be substantially more difficult than following an equivalent > >linear control flow. This makes than more difficult to write and > >check - and increases the maintenance costs. > > FSM's also have the implicit assumption that inputs can be handled > in order of reception, and in a timely fashion. If some inputs need > quicker responses than the time to handle other inputs allows, FSM's have > a problem. This is one reason why threaded programs/OS's can have a very > snappy UI response 'feel' compared to single-threaded - the UI response > can run on a different thread than handling of the UI-invoked events. > This isn't even considering the issues of (long) blocking system calls, > which make it more of an issue. > > FSM's where there are a number of loosely related sets of states > can be very confusing as well. Threads mean you have to worry about > synchronization and locking. Oh well; every technique has plusses and > minuses. > > >>1) SMP scalability > > > >IMHO, this is going to rise in importance over time - and probably > >become the predominant reason for writing threaded code. It's > >becoming more and more difficult to make single processors faster, > >so fast machines will increasingly rely on multiple processors. > > This hasn't happened yet, though it's been predicted for a > decade or more - but I agree, it has to happen eventually. > > -- 1. Both FSM and Posix thread have locking problems. If you are in a state and need to access a data region which is shared by several states you may need to lock the data region. 2. FSMs with gotos are not linear. For instance for a multi connection server you can serve concurrent connections which I did for an FTAM file server. I implemented FTAM (ISO) as a FSM on VMS a decade ago for Touch Communications. The ISO Session layer specification came with its own FSM which the engineer at Touch implemented. Again this was for a multi connection server. -- Amancio Hasty hasty@rah.star-gate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 5 15: 3:18 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id E4FAE14F54 for ; Fri, 5 Nov 1999 15:02:53 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA25554 for ; Sat, 6 Nov 1999 00:02:31 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA01620 for freebsd-arch@freebsd.org; Sat, 6 Nov 1999 00:02:28 +0100 (MET) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 8D3D0153B7 for ; Fri, 5 Nov 1999 15:01:25 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id QAA27871; Fri, 5 Nov 1999 16:01:07 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp01.primenet.com, id smtpdAAAj7ayl2; Fri Nov 5 16:00:53 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id QAA07809; Fri, 5 Nov 1999 16:00:33 -0700 (MST) From: Terry Lambert Message-Id: <199911052300.QAA07809@usr06.primenet.com> Subject: Re: Threads goals version III To: hasty@rah.star-gate.com (Amancio Hasty) Date: Fri, 5 Nov 1999 23:00:29 +0000 (GMT) Cc: tlambert@primenet.com, eischen@vigrid.com, julian@whistle.com, freebsd-arch@freebsd.org In-Reply-To: <199911050048.QAA49642@rah.star-gate.com> from "Amancio Hasty" at Nov 4, 99 04:48:32 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > One could argue that the program should be using a hybrid scheduling > > class in the kernel in order to achieve this effect, rather than > > having to have the idea that you would want to schedule seperate > > kernel schedulable entities within one program. > > How to you propose to handle priorieties for different > "thread thingies" --- "thread thingies" being a yet to > be defined thread implementation. You mean how will a user space scheduler implement the user space scheduling class that handles pthread_attr_setschedpolicy(3) calls? Or do you mean something deeper, such as "since I'm already thinking in terms of kernel threads, how will you let me set kernel scheduling policy for kernel threads, if there aren't any?". > What I am think is that for whatever reason there are applications > which want threads to be running at different priorities for instance > "Kaffe" wants or needs threads running at different priorities. That's no problem for any model, so long as you are talking threads priorities, rather than process priorities. If you are talking process priorities, well, then you're assuming something you shouldn't assume about the underlying implementation because POSIX doesn't give you permission to assume it. 8-). That's not to say that we might not want to implement a user space scheduler assist that can make modifications to which per CPU ready-to-run queue that kernel scheduling contexts take place in, but in my view migration between processors is a user space scheduler decision, based on what ready to run vs. where it ran last vs. what CPU is returning up into user space. I really can't see any other way that the kernel scheduler could know what would or would not be a cache bust, since it's so tightly bound to the particular program implementation; the kernel scheduler is a poor substitute for The Great Karnak. 8-). I'd really like to look at the kernel scheduler as nothing more than something that can hand out resources, and that a quantum is a resource, and that concurrent quanta are an artifact of SMP, and whether or not you get concurrent quanta is totally seperate from your policy decision about which thread in user space gets to run when you have a quantum in hand. Kind of like Linus (Lucy's brother, not Torvalds) and The Great Pumpkin: the quantum comes to visit a thread if it's in the most sincere process. Multiple CPU's bear the same resemblence to the quantum fairy as Elves bear to Santa Claus. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 5 15:22:32 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 1951514BF8 for ; Fri, 5 Nov 1999 15:22:18 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA25767 for ; Sat, 6 Nov 1999 00:22:16 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA01676 for freebsd-arch@freebsd.org; Sat, 6 Nov 1999 00:22:16 +0100 (MET) Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 71FBF153E8 for ; Fri, 5 Nov 1999 15:20:26 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id SAA25395 for ; Fri, 5 Nov 1999 18:15:39 -0500 (EST) Reply-To: Randell Jesup To: arch@freebsd.org Subject: Re: FSM's References: <199911052105.NAA57850@rah.star-gate.com> From: Randell Jesup Date: 05 Nov 1999 19:16:35 +0000 In-Reply-To: Amancio Hasty's message of "Fri, 05 Nov 1999 13:05:55 -0800" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Amancio Hasty writes: >1. Both FSM and Posix thread have locking problems. > > If you are in a state and need to access a data region which is > shared by several states you may need to lock the data region. True. >2. FSMs with gotos are not linear. For instance for a multi connection >server you can serve concurrent connections which I did for an FTAM >file server. > >I implemented FTAM (ISO) as a FSM on VMS a decade ago for Touch >Communications. The ISO Session layer specification came with its own >FSM which the engineer at Touch implemented. Again this was for a multi >connection server. Of course, FSM's can be 'multitasking'/multithreaded - the old PlayNet software I wrote for C64's (later ported to the PC as America Online) used a 'multitasking' FSM (with state pushes/pops as well) to handle chat, Online (Instant) Messages, menus, etc. This certainly works; the only problem is that this assumes that either (a) the time to handle an input is shorter than the time between inputs, or (b) responsiveness to an input doesn't need to be better than the maximum time to handle an input. You do get 'free' implicit locking of datastructures while handling a (single) input. There are also issues of shared context, such as the current directory. In theory, you could call a multitasking (but non-pre-emptive) OS basically the same thing as a really big FSM. Not that this tells you very much useful. I simply find it _far_ easier to work in the paradigm of multitasking, messages, and queues than FSMs. Sometimes FSMs are fine (a lot of windowing events can be handled in a Mac/Windows/Amiga/X-style event loop). Sometimes they're not - a lot of X apps freeze and don't even refresh or let the UI work if a system call hasn't returned, because their UI handling is part of their program (via toolkits). However, we're wandering far afield here (sorry) - the question isn't "are threads useful" - they are. The question is "how do we implement them". -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 5 15:40: 5 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3476614E25 for ; Fri, 5 Nov 1999 15:39:36 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA25973 for ; Sat, 6 Nov 1999 00:38:52 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA01782 for freebsd-arch@freebsd.org; Sat, 6 Nov 1999 00:38:51 +0100 (MET) Received: from rah.star-gate.com (216-200-29-190.snj0.flashcom.net [216.200.29.194]) by hub.freebsd.org (Postfix) with ESMTP id C9C8614E25 for ; Fri, 5 Nov 1999 15:38:12 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.3/8.8.8) with ESMTP id PAA58947; Fri, 5 Nov 1999 15:36:43 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199911052336.PAA58947@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Randell Jesup Cc: arch@freebsd.org Subject: Re: FSM's In-reply-to: Your message of "05 Nov 1999 19:16:35 GMT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Nov 1999 15:36:43 -0800 From: Amancio Hasty Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Amancio Hasty writes: > >1. Both FSM and Posix thread have locking problems. > > > > If you are in a state and need to access a data region which is > > shared by several states you may need to lock the data region. > > True. > > >2. FSMs with gotos are not linear. For instance for a multi connection > >server you can serve concurrent connections which I did for an FTAM > >file server. > > > >I implemented FTAM (ISO) as a FSM on VMS a decade ago for Touch > >Communications. The ISO Session layer specification came with its own > >FSM which the engineer at Touch implemented. Again this was for a multi > >connection server. > > Of course, FSM's can be 'multitasking'/multithreaded - the old > PlayNet software I wrote for C64's (later ported to the PC as America > Online) used a 'multitasking' FSM (with state pushes/pops as well) to > handle chat, Online (Instant) Messages, menus, etc. This certainly works; > the only problem is that this assumes that either (a) the time to handle an > input is shorter than the time between inputs, or (b) responsiveness to an > input doesn't need to be better than the maximum time to handle an input. > You do get 'free' implicit locking of datastructures while handling a > (single) input. > > There are also issues of shared context, such as the current > directory. Which is why you need locking. > In theory, you could call a multitasking (but non-pre-emptive) OS > basically the same thing as a really big FSM. Not that this tells you > very much useful. Well, Von Neumann second computer architecture was an FSM machine to attempt to model the human brain 8) > I simply find it _far_ easier to work in the paradigm of > multitasking, messages, and queues than FSMs. Sometimes FSMs are fine (a > lot of windowing events can be handled in a Mac/Windows/Amiga/X-style event > loop). Sometimes they're not - a lot of X apps freeze and don't even > refresh or let the UI work if a system call hasn't returned, because their > UI handling is part of their program (via toolkits). I think that this is an implementation issue : A few years ago I interviewed over the phone for an X server position at Sun. Top X server from Sun: What do you think X needs Amancio: How about tracing so programmers can have and easier time debugging X applications? Top X server: Do you really think that programmers need tracing? At Touch we didn't have problems tracking down FSM states . > However, we're wandering far afield here (sorry) - the question > isn't "are threads useful" - they are. The question is "how do we > implement them". As an FSM of course , I thought that was clear 8) -- Amancio Hasty hasty@rah.star-gate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 5 15:42:45 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 300CB14E58 for ; Fri, 5 Nov 1999 15:42:34 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA26008 for ; Sat, 6 Nov 1999 00:42:12 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA01820 for freebsd-arch@freebsd.org; Sat, 6 Nov 1999 00:42:12 +0100 (MET) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id B44A21533B for ; Fri, 5 Nov 1999 15:40:25 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id QAA06699; Fri, 5 Nov 1999 16:39:39 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp02.primenet.com, id smtpd006612; Fri Nov 5 16:39:35 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id QAA09960; Fri, 5 Nov 1999 16:39:29 -0700 (MST) From: Terry Lambert Message-Id: <199911052339.QAA09960@usr06.primenet.com> Subject: Re: Threads goals version III To: eischen@vigrid.com (Daniel M. Eischen) Date: Fri, 5 Nov 1999 23:39:29 +0000 (GMT) Cc: rcarter@chomsky.Pinyon.ORG, hasty@rah.star-gate.com, tlambert@primenet.com, julian@whistle.com, freebsd-arch@freebsd.org In-Reply-To: <38224942.6447A8B2@vigrid.com> from "Daniel M. Eischen" at Nov 4, 99 10:04:34 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > One uses pthread_*sched* routines to modify scheduling > > attributes for individual threads. Whether or not those threads > > can get process or system scope, as in the spec, or just process > > scope, that is the question. > > > > If I groked Terry's first missive then the process should first > > set scheduling attributes via sched_setscheduler, if it needs > > something other than SCHED_OTHER (default per process scheduling). > > I'm still studying whether or not this is good enough; i.e., can > > individual threads in a process with a SCHED_FIFO or SCHED_RR > > policies meet QoS goals, and does it provide the flexibility > > needed by an application structured as Daniel's is. > > I don't think it does. I think under Terry's scheme, it wouldn't > be possible to bind a thread to a KSE and place it in a different > scheduler class. It would still be possible to run [user] threads > in different scheduler classes without being bound to a KSE, but > this wouldn't reserve a quantum in which the threads could execute. > So if the application on the whole was at or near it's process > limits, the threads in the real-time (or some other than the > default) scheduler class wouldn't be able to run. > > You could make allowances for this situation and manage accounting > differently for a process running under multiple scheduling classes, > but it still seems simpler to allow (with correct privileges) system > scope threads to be bound to KSEs with their own quantum. OK; I think we're going too deep into implementation details at this point in the game; but I will address the questions. --- Ideally, one would just take the quantum one is given, and say "Oh please sir, may I have another?" in the procesess' best "Oliver Twist" imitation. The quantum belongs to the system, and it is only through the munificence of the system that a grovelling process should be granted a quantum at all. --- In the real world, I realize that some people have implemented code that is dependant on how threads have been implemented, and depends, _almost_ on having kernel threads as backing objects for user space threads, in order to achieve priority banding in what should probably have been two applciations (i.e. PTHRREAD_SCOPE_SYSTEM was a truly bad idea, and now we have to live with/through it). To not get into too much detail, the processes threads are initially scheduled to run on one CPU, and the kernel scheduler code is modified to implement gross CPU affinity, and gross load balancing through process migration at the time a process is placed into a per CPU ready-to-run queue. The sleep queues remain global, and are not modified, while the process is given a simple bitmap and an involuntary context switch call pointer, so that the user space scheduler is never logically interrupted before it runs to completion. In this model, there is very little which is actually done to the kernel sceduler code in terms of creating specific affinity code, and as a result, there is very little that needs to be done to address the starvation and process group affinity issues, partial quantum usage, etc.: all the problems that arise when you start using kernel threads and allowing them to block on you and start trying to map N user space threads to M kernel space threads, for random values of M and N. One could think of running processes on this kernel, ignoring threads for the moment, and achieving high CPU affinity and high load scaling through decreased cache busting as a natural result of the natural CPU affinity that falls out of this model. One could also see that things like the SetiAtHome and RSA and DES challenge code could run much more successfully and equitably in such an environment, and achieving significant improvement over the current SMP scheduling implementation. --- Now for the SMP scalable multithreaded application... For SMP scaling, what you are effectively doing is placing a reservation not in a single read-to-run queue, but the read-to-run queue of multiple CPUs. In the simplest case, this is done incrementally by a user space scheduler making an explicit request to be placed in a second queue, e.g. "reserve me a quantum on a CPU that I'm not already reserving quanta on, please". A simple implementation of this would be: CREATE_NEW_USER_SCHEDULER_STACK CHANGE_TO_NEW_USER_SCHEDULER_STACK rfork( RFADDCPU) CHANGE_TO_PRIOR_USER_SCHEDULER_STACK The point of this would be to: 1) Create a new user space stack, so multiple CPUs can run in the user space scheduler simultaneously 2) Set the new user space stack active 3) Ask another CPU to return to user space on the new stack; this request returns immediately 4) Continue processing on the previous user space stack, since we are still on the previous CPU This would be easier with another parameter so that we could pass the alternate stack down with the rfork(2) call, but it's good enough for now. --- Multiple scheduler reservations, and PTHREAD_SCOPE_SYSTEM... Can each of these scheduler reservations be at different system scheduling priorities? Yes. The implementation of system scoped priorities in this situation is now trivial: If I'm using a "realtime" system scoped priority scheduler reservation, then I, as the user space scheduler, only choose threads to run based on their membership in the list of threads for which that priority is important. I know that something is a praticular priority, because I know the scheduler stack on which the priority was associated: it's the currently running stack from the return from the kernel into the scheduler code in user space. If all of these threads are blocked on events, then I go to sleep via an explicit yield, confident that when the events unblock, they will do so at the high priority and on the scheduling conext on which the call was made. So when I instantiate the high system priority scheduler reservation, I may have to call an explicit yield before I can start running a thread at that priority. The binding of scheduler reservations (kernel call contexts, including a kernel stack, not something as heavyweight as the current kernel threads implementation) in specific system sheduling classes to user space threads in a given process... well, that's essentially a process-level policy decision, to be made by any process that has a high enough priviledge to request such a high priority reservation. This is really a very minimal spreading of the trust model, since you have to trust the whole process to create all its threads at the right priority, if you trust it to create one at a high (e.g. "realtime") priority. As far as "binding" goes, you end up with high and low priority quanta coming back into user space on different user space scheduler stacks -- multiple CPUs/scheduling classes into user space simultaneously -- and what user space thread the scheduler chooses to run as a result is really up to it and the policy set by the programmer. Clearly, you could abuse this, and just as clearly, certain scheduling classes, like "realtime", cut across CPU migration boundaries, so I would expect PTHREAD_SCOPE_SYSTEM to be a last resort for almost all well behaved programs. Failure to do this would pretty surely cause excessive migration between CPUs of the "realtime" scheduler reservation. This is more detail than I wanted to get into outside the scope of a coherent document (it's nearing the size of a white paper right now 8-(...), but since I'm going to be at an IBM UML calls with Archie and Julian all next week, and studying the book this weekend, I didn't want to leave things hanging. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 5 16:10:22 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 8043714E9B for ; Fri, 5 Nov 1999 16:10:03 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id BAA26364 for ; Sat, 6 Nov 1999 01:09:57 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA01954 for freebsd-arch@freebsd.org; Sat, 6 Nov 1999 01:09:56 +0100 (MET) Received: from rah.star-gate.com (216-200-29-190.snj0.flashcom.net [216.200.29.194]) by hub.freebsd.org (Postfix) with ESMTP id 1E42414EFB for ; Fri, 5 Nov 1999 16:09:28 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.3/8.8.8) with ESMTP id QAA59237; Fri, 5 Nov 1999 16:08:00 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199911060008.QAA59237@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert Cc: eischen@vigrid.com, julian@whistle.com, freebsd-arch@freebsd.org Subject: Re: Threads goals version III In-reply-to: Your message of "Fri, 05 Nov 1999 23:00:29 GMT." <199911052300.QAA07809@usr06.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Nov 1999 16:08:00 -0800 From: Amancio Hasty Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > One could argue that the program should be using a hybrid scheduling > > > class in the kernel in order to achieve this effect, rather than > > > having to have the idea that you would want to schedule seperate > > > kernel schedulable entities within one program. > > > > How to you propose to handle priorieties for different > > "thread thingies" --- "thread thingies" being a yet to > > be defined thread implementation. > > > You mean how will a user space scheduler implement the user space > scheduling class that handles pthread_attr_setschedpolicy(3) calls? > > Or do you mean something deeper, such as "since I'm already thinking > in terms of kernel threads, how will you let me set kernel scheduling > policy for kernel threads, if there aren't any?". > Yes I am thinking in terms of kernel "thread thingies" and my question is what you stated last: "how will you let me set kernel scheduling policy for kernel threads since there aren't any" Example: while working on Kaffe to support kernel threads I had no interface to set the relative thread's priorities. Or maybe I missed something... So at this stage we need concrete models for scheduling assuming that we can get over the hump of defining "thread thingies" at the user land level and at the kernel level. -- Amancio Hasty hasty@rah.star-gate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 6 9:52:46 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A311614E97 for ; Sat, 6 Nov 1999 09:52:34 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA15665 for ; Sat, 6 Nov 1999 18:52:32 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA08397 for freebsd-arch@freebsd.org; Sat, 6 Nov 1999 18:52:32 +0100 (MET) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id CD78814C20 for ; Sat, 6 Nov 1999 09:52:21 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p25-dn01kiryunisiki.gunma.ocn.ne.jp [210.132.6.154]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id CAA05329; Sun, 7 Nov 1999 02:50:39 +0900 (JST) Message-ID: <3823EE8E.EC50A1BD@newsguy.com> Date: Sat, 06 Nov 1999 18:02:06 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Terry Lambert Cc: "Daniel M. Eischen" , rcarter@chomsky.Pinyon.ORG, hasty@rah.star-gate.com, julian@whistle.com, freebsd-arch@freebsd.org Subject: Re: Threads goals version III References: <199911052339.QAA09960@usr06.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > ... > Multiple scheduler reservations, and PTHREAD_SCOPE_SYSTEM... > > Can each of these scheduler reservations be at different system > scheduling priorities? > > Yes. Now I don't get it... Since system scope scheduling & multiple (system) scheduling priorities has to work for the single CPU case, how can multiple scheduler reservations help? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org What y'all wanna do? Wanna be hackers? Code crackers? Slackers Wastin' time with all the chatroom yakkers? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 6 13:36:20 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 8DF0014E82 for ; Sat, 6 Nov 1999 13:36:18 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA17699 for ; Sat, 6 Nov 1999 22:36:16 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA12826 for freebsd-arch@freebsd.org; Sat, 6 Nov 1999 22:36:16 +0100 (MET) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 3205B14E82 for ; Sat, 6 Nov 1999 13:35:59 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@d60-025.leach.ucdavis.edu [169.237.60.25]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id NAA33232 for ; Sat, 6 Nov 1999 13:35:59 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id NAA05556 for arch@freebsd.org; Sat, 6 Nov 1999 13:35:59 -0800 (PST) (envelope-from obrien) Date: Sat, 6 Nov 1999 13:35:58 -0800 From: "David O'Brien" To: arch@freebsd.org Subject: new MD5 option Message-ID: <19991106133558.A5539@dragon.nuxi.com> Reply-To: obrien@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am adding an option to md5 to reverse the order of output. From: MD5 (/COPYRIGHT) = 7df8bc77dcee71382ea73eb0ec6a9243 to: MD5 7df8bc77dcee71382ea73eb0ec6a9243 /COPYRIGHT The reson for this addition is to aid visual diffs. They are much easier if the MD5 hashes are nicely lined up. My question is what flag to use. "-r" for reversed output? "-v" for visual diff? -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 6 18:23:55 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id B815614D9A for ; Sat, 6 Nov 1999 18:23:53 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA20223 for ; Sun, 7 Nov 1999 03:23:51 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA14979 for freebsd-arch@freebsd.org; Sun, 7 Nov 1999 03:23:51 +0100 (MET) Received: from friley-160-236.res.iastate.edu (friley-160-236.res.iastate.edu [129.186.160.236]) by hub.freebsd.org (Postfix) with ESMTP id C891D14D9A for ; Sat, 6 Nov 1999 18:23:43 -0800 (PST) (envelope-from cc@137.org) Received: from ameslab.gov (friley-160-235.res.iastate.edu [129.186.160.235]) by friley-160-236.res.iastate.edu (Postfix) with ESMTP id 85679123; Sat, 6 Nov 1999 20:23:33 -0600 (CST) Message-ID: <3824E2A5.D08C3158@ameslab.gov> Date: Sat, 06 Nov 1999 20:23:33 -0600 From: Chris Csanady X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en, ru, ja, ko MIME-Version: 1.0 To: "Daniel C. Sobral" Cc: Terry Lambert , freebsd-arch@freebsd.org Subject: Re: Threads goals version III References: <199911052339.QAA09960@usr06.primenet.com> <3823EE8E.EC50A1BD@newsguy.com> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" wrote: > > Terry Lambert wrote: > > > ... > > > Multiple scheduler reservations, and PTHREAD_SCOPE_SYSTEM... > > > > Can each of these scheduler reservations be at different system > > scheduling priorities? > > > > Yes. > > Now I don't get it... Since system scope scheduling & multiple > (system) scheduling priorities has to work for the single CPU case, > how can multiple scheduler reservations help? I don't see the problem. So, you ask for two quantum--they will end up being on the same CPU in this case. They may still be scheduled in different classes as you please. The idea is that you don't want to do this in general, because you have more context switches than necessary, and increased process migration. Asking for the same number of quanta as CPU's is simply the optimal case. Or, at least that is how I understand it.. Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 6 19:46:36 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A342214BD6 for ; Sat, 6 Nov 1999 19:46:34 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA20711 for ; Sun, 7 Nov 1999 04:46:33 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA15115 for freebsd-arch@freebsd.org; Sun, 7 Nov 1999 04:46:32 +0100 (MET) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 4D68614BD6; Sat, 6 Nov 1999 19:46:22 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from p69-ts5.syd2.zeta.org.au (beefcake.zeta.org.au [203.26.10.12]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id OAA17978; Sun, 7 Nov 1999 14:51:55 +1100 Date: Sun, 7 Nov 1999 14:46:18 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: obrien@freebsd.org Cc: arch@freebsd.org Subject: Re: new MD5 option In-Reply-To: <19991106133558.A5539@dragon.nuxi.com> 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 > I am adding an option to md5 to reverse the order of output. > ... > My question is what flag to use. "-r" for reversed output? "-v" for > visual diff? "-r" for "right" :-). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 6 19:58: 6 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 1ED2F14E15 for ; Sat, 6 Nov 1999 19:57:57 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA20797 for ; Sun, 7 Nov 1999 04:57:56 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA15151 for freebsd-arch@freebsd.org; Sun, 7 Nov 1999 04:57:56 +0100 (MET) Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 37ED014C35; Sat, 6 Nov 1999 19:57:46 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #2) id 11kJSb-0000wp-00; Sat, 6 Nov 1999 20:57:45 -0700 Message-ID: <3824F8B7.7DCEAFD1@softweyr.com> Date: Sat, 06 Nov 1999 20:57:43 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: obrien@freebsd.org Cc: arch@freebsd.org Subject: Re: new MD5 option References: <19991106133558.A5539@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David O'Brien wrote: > > I am adding an option to md5 to reverse the order of output. > > From: > MD5 (/COPYRIGHT) = 7df8bc77dcee71382ea73eb0ec6a9243 > > to: > MD5 7df8bc77dcee71382ea73eb0ec6a9243 /COPYRIGHT > > The reson for this addition is to aid visual diffs. They are much easier > if the MD5 hashes are nicely lined up. Good idea. > My question is what flag to use. "-r" for reversed output? "-v" for > visual diff? I'd prefer -r, since -v generally means "verbose", but don't feel strongly about it. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 6 20: 9:40 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id B585C14CC3 for ; Sat, 6 Nov 1999 20:09:38 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA20900 for ; Sun, 7 Nov 1999 05:09:34 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA15212 for freebsd-arch@freebsd.org; Sun, 7 Nov 1999 05:09:34 +0100 (MET) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 9EED314CC3 for ; Sat, 6 Nov 1999 20:09:06 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.3/frmug-2.5/nospam) with UUCP id FAA26474 for arch@freebsd.org; Sun, 7 Nov 1999 05:09:05 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id D40D28711; Sun, 7 Nov 1999 02:13:20 +0100 (CET) Date: Sun, 7 Nov 1999 02:13:20 +0100 From: Ollivier Robert To: arch@freebsd.org Subject: Re: new MD5 option Message-ID: <19991107021320.A10152@keltia.freenix.fr> Mail-Followup-To: arch@freebsd.org References: <19991106133558.A5539@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0pre2i In-Reply-To: <19991106133558.A5539@dragon.nuxi.com> X-Operating-System: FreeBSD 4.0-CURRENT/ELF AMD-K6/200 & 2x PPro/200 SMP Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to David E . O'Brien: > My question is what flag to use. "-r" for reversed output? "-v" for > visual diff? "-r" seems logical to me. "-v" is more for genercic verbose stuff. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #75: Tue Nov 2 21:03:12 CET 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 6 23:51:53 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A320014EF2 for ; Sat, 6 Nov 1999 23:51:51 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id IAA22475 for ; Sun, 7 Nov 1999 08:51:49 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA15640 for freebsd-arch@freebsd.org; Sun, 7 Nov 1999 08:51:48 +0100 (MET) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 5D6BF14EF2 for ; Sat, 6 Nov 1999 23:51:19 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p24-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.153]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id QAA15701; Sun, 7 Nov 1999 16:51:06 +0900 (JST) Message-ID: <38252EE8.5F627E51@newsguy.com> Date: Sun, 07 Nov 1999 16:48:56 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Chris Csanady Cc: Terry Lambert , freebsd-arch@freebsd.org Subject: Re: Threads goals version III References: <199911052339.QAA09960@usr06.primenet.com> <3823EE8E.EC50A1BD@newsguy.com> <3824E2A5.D08C3158@ameslab.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chris Csanady wrote: > > I don't see the problem. So, you ask for two quantum--they will end > up being on the same CPU in this case. They may still be scheduled in > different classes as you please. > > The idea is that you don't want to do this in general, because you > have more context switches than necessary, and increased process > migration. Asking for the same number of quanta as CPU's is simply > the optimal case. > > Or, at least that is how I understand it.. /me mmmms Let's see what Terry says. What you describe makes sense, but he won't be able to use so few words. :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org What y'all wanna do? Wanna be hackers? Code crackers? Slackers Wastin' time with all the chatroom yakkers? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message