From owner-freebsd-arch Sun May 14 1: 4: 0 2000 Delivered-To: freebsd-arch@freebsd.org Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net [194.217.242.41]) by hub.freebsd.org (Postfix) with ESMTP id C8BDF37B52B for ; Sun, 14 May 2000 01:03:56 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1) id 12qtNT-0004rI-0C; Sun, 14 May 2000 08:03:55 +0000 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 JAA04144; Sun, 14 May 2000 09:08:03 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 14 May 2000 09:08:20 +0100 (BST) From: Doug Rabson To: Chuck Paterson Cc: arch@freebsd.org Subject: Re: A new api for asynchronous task execution In-Reply-To: <200005132342.RAA01739@berserker.bsdi.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 Sat, 13 May 2000, Chuck Paterson wrote: > > } > }The system defines specific implementations of queues which are drained at > }particular times (initially I have defined one using SWI). I want to make > }it as easy as possible to define different lightweight queues for various > }types of work. The 'enqueue' function pointer in the taskqueue structure > }defines the run policy for the queue. > } > > I would agree that there is no reason to change what you > have for generic queueing. But for taskqueue_swi currently > and a possibly others in the future you not only need to > queue the event you want to cause a software interrupt to occur > at the soonest reasonable time. Putting the item on the work > queue does not seem sufficient. In particular I would argue the > following should be avoided > > > taskqueue_enqueue(struct taskqueue *queue, struct task *task) > { > int s = splhigh(); > > /* > * Count multiple enqueues. > */ > if (task->pending) { > task->pending++; > return; > } > STAILQ_INSERT_TAIL(&queue->queue, task, link); > task->pending = 1; > if (queue->enqueue) > queue->enqueue(queue); > > if (queueu == taskqueue_swi) <------ > setsoftaskqueue(); <------ For taskqueue_swi, this is exactly what happens in the call to queue->enqueue(queue) above. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 14 1: 4:51 2000 Delivered-To: freebsd-arch@freebsd.org Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by hub.freebsd.org (Postfix) with ESMTP id 1F6E837B87E for ; Sun, 14 May 2000 01:04:48 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 12qtOI-0008Wt-0B; Sun, 14 May 2000 08:04:46 +0000 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 JAA04748; Sun, 14 May 2000 09:09:02 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 14 May 2000 09:09:19 +0100 (BST) From: Doug Rabson To: Amancio Hasty Cc: arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution In-Reply-To: <200005132336.QAA43041@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 Sat, 13 May 2000, Amancio Hasty wrote: > Hi Doug! > > Great idea!! > > Say, how you thought of how to to map a system call such as open, > read,write, or close to your new system call? This api is not a system call at all. Its a new facility for use inside the kernel. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 14 1:12:42 2000 Delivered-To: freebsd-arch@freebsd.org 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 B74C037B52B for ; Sun, 14 May 2000 01:12:40 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost [127.0.0.1]) by rah.star-gate.com (8.9.3/8.9.3) with ESMTP id BAA46327; Sun, 14 May 2000 01:12:03 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <200005140812.BAA46327@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Doug Rabson Cc: arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution In-reply-to: Your message of "Sun, 14 May 2000 09:09:19 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 May 2000 01:12:03 -0700 From: Amancio Hasty Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Sat, 13 May 2000, Amancio Hasty wrote: > > > Hi Doug! > > > > Great idea!! > > > > Say, how you thought of how to to map a system call such as open, > > read,write, or close to your new system call? > > This api is not a system call at all. Its a new facility for use inside > the kernel. > I know that the API will be used by kernel routines such as device drivers;nevertheless, I think that the new kernel routine can be used to implement async system calls 8) Cheers -- 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 May 14 5: 6:45 2000 Delivered-To: freebsd-arch@freebsd.org Received: from cmailg4.svr.pol.co.uk (cmailg4.svr.pol.co.uk [195.92.195.174]) by hub.freebsd.org (Postfix) with ESMTP id E22E837BA81 for ; Sun, 14 May 2000 05:06:41 -0700 (PDT) (envelope-from n_hibma@calcaphon.com) Received: from [195.92.67.23] (helo=mail18.svr.pol.co.uk) by cmailg4.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 12qxAO-000181-00 for arch@freebsd.org; Sun, 14 May 2000 13:06:40 +0100 Received: from modem-123.porcupine-puffer.dialup.pol.co.uk ([62.137.50.251] helo=henny.webweaving.org) by mail18.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 12qxAN-0005v0-00 for arch@FreeBSD.ORG; Sun, 14 May 2000 13:06:39 +0100 Received: from localhost (localhost [127.0.0.1]) by henny.webweaving.org (8.9.3/8.9.3) with ESMTP id DAA78124 for ; Sun, 14 May 2000 03:25:50 +0100 (BST) (envelope-from n_hibma@calcaphon.com) Date: Sun, 14 May 2000 03:25:50 +0100 (BST) From: Nick Hibma X-Sender: n_hibma@localhost Reply-To: Nick Hibma To: FreeBSD Arch Mailing List Subject: kobj 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've had a bit of a browse through the kobj source code to see what you'd done to the newbus stuff in order to separate the two. One of my main issues with it is that kobj_compile_methods panics in low memory situations. It should return an error code / NULL. It's not necessarily fatal if an object can't be created. I consider kobj very similar to malloc, except that it embeds a bit of functionality in the allocated struct. Second, two minor nits (or signs of brain damage on my side). You call kobj_init twice in subr_bus.c:make_device. And you call kobj_class_compile in subr_bus.c:root_bus_module_handler explicitly and through kobj_init, implicitly. One last thing: KOBJ_CACHE_SIZE is by default set to 256. I find that rather large (1kb) considering the number of methods in use currently in newbus (per file, possibly multiple MODULES): 15 ./dev/iicbus/iicsmb.c 16 ./i386/i386/nexus.c 18 ./dev/eisa/eisaconf.c 19 ./dev/mca/mca_bus.c 20 ./pccard/pccard_nbk.c 21 ./dev/pccard/pccard.c 22 ./dev/ata/ata-all.c 23 ./pci/pci.c 27 ./isa/isa_common.c 29 ./pci/pcisupport.c I suggest something like 120 or less (less than a power of two to make the object fit in an allocation of a power of 2. Hope these comments are of any use. Nick -- n_hibma@webweaving.org n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 14 5: 6:59 2000 Delivered-To: freebsd-arch@freebsd.org Received: from cmailg1.svr.pol.co.uk (cmailg1.svr.pol.co.uk [195.92.195.171]) by hub.freebsd.org (Postfix) with ESMTP id AB75B37B9F1; Sun, 14 May 2000 05:06:51 -0700 (PDT) (envelope-from n_hibma@calcaphon.com) Received: from [195.92.67.23] (helo=mail18.svr.pol.co.uk) by cmailg1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 12qxAY-0004cR-00; Sun, 14 May 2000 13:06:50 +0100 Received: from modem-123.porcupine-puffer.dialup.pol.co.uk ([62.137.50.251] helo=henny.webweaving.org) by mail18.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 12qxAW-0005v0-00; Sun, 14 May 2000 13:06:49 +0100 Received: from localhost (localhost [127.0.0.1]) by henny.webweaving.org (8.9.3/8.9.3) with ESMTP id PAA76984; Sat, 13 May 2000 15:28:35 +0100 (BST) (envelope-from n_hibma@calcaphon.com) Date: Sat, 13 May 2000 15:28:35 +0100 (BST) From: Nick Hibma X-Sender: n_hibma@localhost Reply-To: Nick Hibma To: Doug Rabson Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution 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 > > > void (*func)(void *, int); /* task handler */ > > > > What's the second argument? > > Its explained later on in the text. Its a count of how many times the task > was queued since the queue was last run. (If it is correct C) I would like to see explicit names in function arguments. I know that in general that that is not your style, if it is not needed, but it certainly makes reading the header / manpage file a lot easier, i.e. you only have to scan the first page to see what you need, instead of having to read the page. After all, who needs manpages if you have a header file (and ctags :-) Nick > > Any sense in having statically-initialised task queues? > > > > TASK_QUEUE(name); > > I thought of this but couldn't quite decide if it was useful. I don't > expect there to be many queues around. To start with, there will only be > the SWI queue. I think it is a valid point. Otherwise you might get an increased number of modules that require init on load. This functionality is bound to become very useful in cases where you want to execute things in a batched fashion. Apart from that, IMHO it should be TASK_QUEUE(name, enqueue_fn) to match taskqueue_init. Nick -- n_hibma@webweaving.org n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 14 5: 7:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from cmailg3.svr.pol.co.uk (cmailg3.svr.pol.co.uk [195.92.195.173]) by hub.freebsd.org (Postfix) with ESMTP id D4CB537BA81 for ; Sun, 14 May 2000 05:06:52 -0700 (PDT) (envelope-from n_hibma@calcaphon.com) Received: from [195.92.67.23] (helo=mail18.svr.pol.co.uk) by cmailg3.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 12qxAY-0002PC-00 for arch@freebsd.org; Sun, 14 May 2000 13:06:50 +0100 Received: from modem-123.porcupine-puffer.dialup.pol.co.uk ([62.137.50.251] helo=henny.webweaving.org) by mail18.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 12qxAX-0005vC-00 for arch@freebsd.org; Sun, 14 May 2000 13:06:49 +0100 Received: from localhost (localhost [127.0.0.1]) by henny.webweaving.org (8.9.3/8.9.3) with ESMTP id PAA76989; Sat, 13 May 2000 15:30:16 +0100 (BST) (envelope-from n_hibma@calcaphon.com) Date: Sat, 13 May 2000 15:30:16 +0100 (BST) From: Nick Hibma X-Sender: n_hibma@localhost Reply-To: Nick Hibma To: Poul-Henning Kamp Cc: Doug Rabson , arch@freebsd.org Subject: Re: A new api for asynchronous task execution In-Reply-To: <3564.958209950@critter.freebsd.dk> 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'm planning to add a new system to the kernel which should make it much > >easier for drivers (especially loadable drivers) to use software > >interrupts to implement split-level interrupt handlers. The api was > >inspired by the Linux tqueue system but the implementation is quite > >different. > > Yes, PLEASE! I rest my case (on the abuse this thing is going to get) ... :-) Nick -- n_hibma@webweaving.org n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 14 7:11: 8 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id 9E35937BDC4 for ; Sun, 14 May 2000 07:11:05 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id IAA04077; Sun, 14 May 2000 08:11:00 -0600 (MDT) Message-Id: <200005141411.IAA04077@berserker.bsdi.com> To: Doug Rabson Cc: arch@freebsd.org Subject: Re: A new api for asynchronous task execution From: Chuck Paterson Date: Sun, 14 May 2000 08:11:00 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug, First, in continuing this thread I'm most trying to make sure I have managed to get my point across, not necessarily convince you that you really need to make a change now. Sorry, but I'm not sure I'm parsing what you said correctly. I believe that you are saying that the line two lines I added will actually be in taskqueue_enqueue. }> if (queue == taskqueue_swi) <------ }> setsoftaskqueue(); <------ } }For taskqueue_swi, this is exactly what happens in the call to }queue->enqueue(queue) above. } Then in a kernel which as more software threads you will soon have the following which as far as I can tell won't be optimized out even if if taskqueue_enqueue() is implemented as a macro: if (queue == taskqueue_swi) setsoftaskqueue() if (queue == taskqueue_foo) setsoftaskfoo() if (queue == taskqueue_bar) setsoftaskbar() if (queue == taskqueue_xxx) setsoftaskxxx() This can be avoided by having a macro pre-defined for these uses for now which would only be #define TASKQUEUE(task, flag) /* flag ignored for now* \ taskqueue_enqueue(taskqueue_swi, task); \ setsofttaskqueueu() The macro name TASKQUEUE may well be inappropriate. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 14 7:33:58 2000 Delivered-To: freebsd-arch@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id E2E2E37B649 for ; Sun, 14 May 2000 07:33:52 -0700 (PDT) (envelope-from ben@scientia.demon.co.uk) Received: from strontium.scientia.demon.co.uk ([192.168.91.36] ident=exim) by scientia.demon.co.uk with esmtp (Exim 3.12 #1) id 12qzJk-00045a-00; Sun, 14 May 2000 15:24:28 +0100 Received: (from ben) by strontium.scientia.demon.co.uk (Exim 3.12 #7) id 12qzJj-0002eq-00; Sun, 14 May 2000 15:24:27 +0100 Date: Sun, 14 May 2000 15:24:27 +0100 From: Ben Smithurst To: Dag-Erling Smorgrav Cc: arch@FreeBSD.org Subject: Re: fetch(1) Message-ID: <20000514152427.Q10128@strontium.scientia.demon.co.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > I'm still waiting for comments about my libfetch-based fetch(1). Get > the latest tarball from . > > (note that it needs -CURRENT's libfetch to work) It seems that fetching an FTP url via an HTTP proxy server is now broken. Setting HTTP_PROXY=www-cache:8080 used to work for FTP too, but it doesn't anymore. ben@lithium:~$ export HTTP_PROXY=www-cache:8080 ben@lithium:~$ ktrace fetch ftp://scientia.demon.co.uk/ libfetch: No error (250 Requested file action okay, completed) libfetch: File is not available (550 File unavailable (e.g., file not found, no access)) ben@lithium:~$ kdump | grep GET 4639 fetch CALL ioctl(0x1,TIOCGETA,0xbfbff238) 4639 fetch CALL ioctl(0x1,TIOCGETA,0xbfbff548) I don't see an HTTP GET request there. This needs fixing before being imported. Also, a minor nit in the manual page for libfetch: The FTP and HTTP related functions use the HTTP_PROXY and FTP_PROXY envi- ronment variables, respectively, as the address of a proxy server to use for transferring files. I think you want to swap around one pair of "FTP" and "HTTP" or it implies FTP uses HTTP_PROXY and vice versa. -- Ben Smithurst / ben@scientia.demon.co.uk / PGP: 0x99392F7D To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 14 8: 6:30 2000 Delivered-To: freebsd-arch@freebsd.org Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) by hub.freebsd.org (Postfix) with ESMTP id 97EB037B6A2 for ; Sun, 14 May 2000 08:06:27 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 12qzyL-000Dsq-0K; Sun, 14 May 2000 15:06:25 +0000 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 QAA62400; Sun, 14 May 2000 16:10:45 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 14 May 2000 16:10:57 +0100 (BST) From: Doug Rabson To: Chuck Paterson Cc: arch@freebsd.org Subject: Re: A new api for asynchronous task execution In-Reply-To: <200005141411.IAA04077@berserker.bsdi.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, 14 May 2000, Chuck Paterson wrote: > Doug, > > First, in continuing this thread I'm most trying > to make sure I have managed to get my point across, not > necessarily convince you that you really need to make > a change now. I understand that. Email is not always the best medium for communication :-). > Sorry, but I'm not sure I'm parsing what you said > correctly. I believe that you are saying that the line two > lines I added will actually be in taskqueue_enqueue. What I am saying is that when you call taskqueue_enqueue(&taskqueue_swi, foo), the task will be added to taskqueue_swi and the function taskqueue_swi_enqueue will be called via the 'enqueue' field of taskqueue_swi. This calls setsofttq() which arranges for a software interrupt to call taskqueue_swi_run() when conditions are suitable. This will in turn call taskqueue_run() to drain the queue. > Then in a kernel which as more software threads you will soon have > the following which as far as I can tell won't be optimized out > even if if taskqueue_enqueue() is implemented as a macro: > > if (queue == taskqueue_swi) > setsoftaskqueue() > if (queue == taskqueue_foo) > setsoftaskfoo() > if (queue == taskqueue_bar) > setsoftaskbar() > if (queue == taskqueue_xxx) > setsoftaskxxx() Each of these queues could be implemented within the current model by using different functions in the queue->enqueue field, each of which would perform the relavent setsoftxxx(). The intention for disassociating the implementation of scheduling and running a queue from the queue itself is to make it possible to use the queues for purposes other than simple software interrupts. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 14 9:13:29 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id 248BD37B81F for ; Sun, 14 May 2000 09:13:25 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (qmail 27283 invoked from network); 14 May 2000 16:13:21 -0000 Received: from bde.zeta.org.au (203.2.228.102) by gidora.zeta.org.au with SMTP; 14 May 2000 16:13:21 -0000 Date: Mon, 15 May 2000 02:13:19 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Nick Hibma Cc: Doug Rabson , Mike Smith , arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution 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 Sat, 13 May 2000, Nick Hibma wrote: > > > > void (*func)(void *, int); /* task handler */ > > > > > > What's the second argument? > > > > Its explained later on in the text. Its a count of how many times the task > > was queued since the queue was last run. > > (If it is correct C) I would like to see explicit names in function > arguments. I know that in general that that is not your style, if it is style(9) requires it for kernel interfaces although not for application interfaces. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 14 10: 9:17 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id 3395037BE03 for ; Sun, 14 May 2000 10:09:12 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (qmail 29067 invoked from network); 14 May 2000 17:09:10 -0000 Received: from bde.zeta.org.au (203.2.228.102) by gidora.zeta.org.au with SMTP; 14 May 2000 17:09:10 -0000 Date: Mon, 15 May 2000 03:09:07 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Doug Rabson Cc: Amancio Hasty , arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution 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, 14 May 2000, Doug Rabson wrote: > On Sat, 13 May 2000, Amancio Hasty wrote: > > > Hi Doug! > > > > Great idea!! > > > > Say, how you thought of how to to map a system call such as open, > > read,write, or close to your new system call? > > This api is not a system call at all. Its a new facility for use inside > the kernel. Doesn't the "a" in api stand for "application"? Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 14 10:31:58 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id 2520C37B5A3 for ; Sun, 14 May 2000 10:31:53 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id LAA04793; Sun, 14 May 2000 11:31:33 -0600 (MDT) Message-Id: <200005141731.LAA04793@berserker.bsdi.com> To: Doug Rabson Cc: Arun Sharma , freebsd-arch@freebsd.org Subject: Re: A new api for asynchronous task execution From: Chuck Paterson Date: Sun, 14 May 2000 11:31:32 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG While writing up this I noticed a trivial bug taskqueue_enqueue(struct taskqueue *queue, struct task *task) { int s = splhigh(); /* * Count multiple enqueues. */ if (task->pending) { task->pending++; return; <---- really need a splx before this } } }I agree that the queue should have a mutex to protect itself. Since we }haven't finalised the api for mutex locking (we will almost certainly use }the BSD/OS one), I can't add anything yet but I will when the new SMP }work starts. FYI, the current BSD/OS mutex's have a string associated with them, ie there name. This name is used for debugging (checking lock order) and perhaps for blowing locks open at panic time. Mutex's which aren't part of a group of a unique name, an example of this might be "ipqlock". For mutex's which are all really the same they share the same name such as "vnode interlock". There is also the issue of what flags are passed in to initialize the mutex, and for that matter flags used in acquiring the mutex. I guess I should for now just point out some of the issues. 1) It would be useful to have meaningful name associated with a mutex when initializing the mutex associated with a taskqueue. 2) There are flags needed with initializing the mutex associated with a taskqueue. 3) When acquiring the mutex associated with a queue it wants to in general not be of type M_SPIN, but sometimes it will. 4) As proposed now the mutex protecting the queue often does not want to be held while the enqueueing function is called. This is particularly true if the enqueueing function may cause an immediate context switch. 5) Even the taskqueue_run really wants to just know what type of mutex is present. In some ways the implementation of taskqueue_enqueue() is not as important to get right from the start as the calling sequence to it. There are almost certainly going to be lots more users of the swi taskqueue than anything else and changing the few actual implementation of the enqueuer function and init function seem like not a big deal. I have included just some sketches of how you could deal with some of this. Just something to think about The following is very slightly slower because the type of mutex is not known at compile times, but it makes it possible to not have to totally change to model. Chuck struct taskqueue { STAILQ_HEAD(, task) queue; mtx_t mtx; int mtx_flags; void (*enqueue)(struct taskqueue *queue); }; void taskqueue_init(struct taskqueue *queue, void (*enqueue)(struct taskqueue *queue), char *name, int flags) { STAILQ_INIT(&queue->queue); queue->enqueue = enqueue; queue->mtx_flags = flags & TQ_SPIN ? M_SPIN, M_DEF; mtx_init(&queue->mtx, name, queueu->mtx_flags; } void taskqueue_enqueue(struct taskqueue *queue, struct task *task) { mtx_enter(&queue->mtx, queue->mtx_flags); /* * Count multiple enqueues. */ if (task->pending) { task->pending++; mtx_exit(&queue->mtx, queue->mtx_flags); return; } STAILQ_INSERT_TAIL(&queue->queue, task, link); task->pending = 1; mtx_exit(&queue->mtx, queue->mtx_flags); if (queue->enqueue) queue->enqueue(queue); } void taskqueue_run(struct taskqueue *queue) { int s; struct task *task; int pending; mtx_enter(&queue->mtx, queue->mtx_flags); while (STAILQ_FIRST(&queue->queue)) { /* * Carefully remove the first task from the queue and * zero its pending count. */ task = STAILQ_FIRST(&queue->queue); STAILQ_REMOVE_HEAD(&queue->queue, link); pending = task->pending; task->pending = 0; mtx_exit(&queue->mtx, queue->mtx_flags); task->func(task->arg, pending); mtx_enter(&queue->mtx, queue->mtx_flags); } mtx_exit(&queue->mtx, queue->mtx_flags); } /* * The following will probably work, but cheating * on locking probably ought not to be done until it has been * shown that in the particular path that the performance * is worth the potential risk. */ void taskqueue_run(struct taskqueue *queue) { int s; struct task *task; int pending; while (STAILQ_FIRST(&queue->queue)) { mtx_enter(&queue->mtx, queue->mtx_flags); /* * Carefully remove the first task from the queue and * zero its pending count. */ task = STAILQ_FIRST(&queue->queue); STAILQ_REMOVE_HEAD(&queue->queue, link); pending = task->pending; task->pending = 0; mtx_exit(&queue->mtx, queue->mtx_flags); task->func(task->arg, pending); } } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 14 12:36:45 2000 Delivered-To: freebsd-arch@freebsd.org Received: from peace.mahoroba.org (peace.calm.imasy.or.jp [202.227.26.34]) by hub.freebsd.org (Postfix) with ESMTP id 68C3637B5FA for ; Sun, 14 May 2000 12:36:37 -0700 (PDT) (envelope-from ume@mahoroba.org) Received: from localhost (IDENT:HiQ5BEdt1BkHxWAK6c4IIJWZjo+1cGTWSZ++Saj6taXPJzoUo5OzOdpw9NpqVldy@localhost [::1]) by peace.mahoroba.org (8.10.1/3.7W-peace) with ESMTP id e4EJVwF65961; Mon, 15 May 2000 04:31:58 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Mon, 15 May 2000 04:31:58 +0900 (JST) Message-Id: <200005141931.e4EJVwF65961@peace.mahoroba.org> To: ben@scientia.demon.co.uk Cc: des@flood.ping.uio.no, arch@FreeBSD.org Subject: Re: fetch(1) In-Reply-To: <20000514152427.Q10128@strontium.scientia.demon.co.uk> References: <20000514152427.Q10128@strontium.scientia.demon.co.uk> X-Mailer: xcite1.20> Mew version 1.94.2 on Emacs 20.6 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= X-PGP-Public-Key: http://www.imasy.org/~ume/publickey.asc X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.org/~ume/ X-OS: FreeBSD 5.0-CURRENT Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_May_15_04:31:55_2000_601)--" Content-Transfer-Encoding: 7bit From: Hajimu UMEMOTO (=?ISO-2022-JP?B?GyRCR19LXBsoQiA=?= =?ISO-2022-JP?B?GyRCSCUbKEI=?=) X-Dispatcher: imput version 20000228(IM140) Lines: 171 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ----Next_Part(Mon_May_15_04:31:55_2000_601)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit >>>>> On Sun, 14 May 2000 15:24:27 +0100 >>>>> Ben Smithurst said: ben> Dag-Erling Smorgrav wrote: > I'm still waiting for comments about my libfetch-based fetch(1). Get > the latest tarball from . > > (note that it needs -CURRENT's libfetch to work) ben> It seems that fetching an FTP url via an HTTP proxy server is now ben> broken. Setting HTTP_PROXY=www-cache:8080 used to work for FTP too, but ben> it doesn't anymore. How about this patch? If OK, I'll commit it. ----Next_Part(Mon_May_15_04:31:55_2000_601)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Description: libfetch-proxy.diff Content-Disposition: attachment; filename="libfetch-proxy.diff" Index: libfetch/fetch.c diff -u libfetch/fetch.c.orig libfetch/fetch.c --- libfetch/fetch.c.orig Fri May 12 01:35:25 2000 +++ libfetch/fetch.c Mon May 15 04:02:11 2000 @@ -69,13 +69,18 @@ FILE * fetchGet(struct url *URL, char *flags) { + int direct = (flags && strchr(flags, 'd')); + if (strcasecmp(URL->scheme, "file") == 0) return fetchGetFile(URL, flags); else if (strcasecmp(URL->scheme, "http") == 0) return fetchGetHTTP(URL, flags); - else if (strcasecmp(URL->scheme, "ftp") == 0) + else if (strcasecmp(URL->scheme, "ftp") == 0) { + if (!direct && + getenv("FTP_PROXY") == NULL && getenv("HTTP_PROXY") != NULL) + return fetchGetHTTP(URL, flags); return fetchGetFTP(URL, flags); - else { + } else { _url_seterr(URL_BAD_SCHEME); return NULL; } @@ -88,13 +93,18 @@ FILE * fetchPut(struct url *URL, char *flags) { + int direct = (flags && strchr(flags, 'd')); + if (strcasecmp(URL->scheme, "file") == 0) return fetchPutFile(URL, flags); else if (strcasecmp(URL->scheme, "http") == 0) return fetchPutHTTP(URL, flags); - else if (strcasecmp(URL->scheme, "ftp") == 0) + else if (strcasecmp(URL->scheme, "ftp") == 0) { + if (!direct && + getenv("FTP_PROXY") == NULL && getenv("HTTP_PROXY") != NULL) + return fetchPutHTTP(URL, flags); return fetchPutFTP(URL, flags); - else { + } else { _url_seterr(URL_BAD_SCHEME); return NULL; } @@ -107,13 +117,18 @@ int fetchStat(struct url *URL, struct url_stat *us, char *flags) { + int direct = (flags && strchr(flags, 'd')); + if (strcasecmp(URL->scheme, "file") == 0) return fetchStatFile(URL, us, flags); else if (strcasecmp(URL->scheme, "http") == 0) return fetchStatHTTP(URL, us, flags); - else if (strcasecmp(URL->scheme, "ftp") == 0) + else if (strcasecmp(URL->scheme, "ftp") == 0) { + if (!direct && + getenv("FTP_PROXY") == NULL && getenv("HTTP_PROXY") != NULL) + return fetchStatHTTP(URL, us, flags); return fetchStatFTP(URL, us, flags); - else { + } else { _url_seterr(URL_BAD_SCHEME); return -1; } @@ -126,13 +141,18 @@ struct url_ent * fetchList(struct url *URL, char *flags) { + int direct = (flags && strchr(flags, 'd')); + if (strcasecmp(URL->scheme, "file") == 0) return fetchListFile(URL, flags); else if (strcasecmp(URL->scheme, "http") == 0) return fetchListHTTP(URL, flags); - else if (strcasecmp(URL->scheme, "ftp") == 0) + else if (strcasecmp(URL->scheme, "ftp") == 0) { + if (!direct && + getenv("FTP_PROXY") == NULL && getenv("HTTP_PROXY") != NULL) + return fetchListHTTP(URL, flags); return fetchListFTP(URL, flags); - else { + } else { _url_seterr(URL_BAD_SCHEME); return NULL; } Index: libfetch/http.c diff -u libfetch/http.c.orig libfetch/http.c --- libfetch/http.c.orig Fri May 12 01:35:27 2000 +++ libfetch/http.c Mon May 15 04:24:03 2000 @@ -311,10 +311,16 @@ if (!URL->port) { struct servent *se; - if ((se = getservbyname("http", "tcp")) != NULL) - URL->port = ntohs(se->s_port); + if (strcasecmp(URL->scheme, "ftp") == 0) + if ((se = getservbyname("ftp", "tcp")) != NULL) + URL->port = ntohs(se->s_port); + else + URL->port = 21; else - URL->port = 80; + if ((se = getservbyname("http", "tcp")) != NULL) + URL->port = ntohs(se->s_port); + else + URL->port = 80; } /* attempt to connect to proxy server */ @@ -363,6 +369,8 @@ /* if no proxy is configured or could be contacted, try direct */ if (sd == -1) { + if (strcasecmp(URL->scheme, "ftp") == 0) + goto ouch; if ((sd = _fetch_connect(URL->host, URL->port, verbose)) == -1) goto ouch; } @@ -394,8 +402,8 @@ /* send request (proxies require absolute form, so use that) */ if (verbose) - _fetch_info("requesting http://%s:%d%s", - URL->host, URL->port, URL->doc); + _fetch_info("requesting %s://%s:%d%s", + URL->scheme, URL->host, URL->port, URL->doc); _http_cmd(f, "%s %s://%s:%d%s HTTP/1.1" ENDL, op, URL->scheme, URL->host, URL->port, URL->doc); ----Next_Part(Mon_May_15_04:31:55_2000_601)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Description: My Signature Content-Disposition: attachment; filename=".signature-world" Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@FreeBSD.org http://www.imasy.org/~ume/ ----Next_Part(Mon_May_15_04:31:55_2000_601)---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 14 12:49:46 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.cdrom.com (adsl-63-202-176-114.dsl.snfc21.pacbell.net [63.202.176.114]) by hub.freebsd.org (Postfix) with ESMTP id AFAB137B6F8 for ; Sun, 14 May 2000 12:49:42 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id MAA09452; Sun, 14 May 2000 12:48:24 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200005141948.MAA09452@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Nick Hibma Cc: Doug Rabson , arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution In-reply-to: Your message of "Sat, 13 May 2000 15:28:35 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 May 2000 12:48:24 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Any sense in having statically-initialised task queues? > > > > > > TASK_QUEUE(name); > > > > I thought of this but couldn't quite decide if it was useful. I don't > > expect there to be many queues around. To start with, there will only be > > the SWI queue. > > I think it is a valid point. Otherwise you might get an increased number > of modules that require init on load. This functionality is bound to > become very useful in cases where you want to execute things > in a batched fashion. > > Apart from that, IMHO it should be > > TASK_QUEUE(name, enqueue_fn) > > to match taskqueue_init. Indeed. I've actually been thinking about this for a little longer, and there are a couple of things that come to mind. We have a number of different callout list implementation kicking around in the kernel at the moment; - the EVENTHANDLER stuff - the optimised callout list handling in kern_timeout.c - a few ad-hoc leftovers like config_intrhook that should have been EVENTHANDLERed but weren't I don't think that kern_timeout's domain should be encroached upon, but all of the rest of this is still worth subsuming if you're going to produce a "better" API. To do that, you really only need a few extra things: - The ability to search for a taskqueue by name (I really don't like the hard binding that's required by having the linker do this). - Some more flexibility in the enqueueing of tasks, particularly the ability to specify a priority so that tasks on the queue are executed in an ordered fashion. - Static taskqueue initialisers. None of these are particularly heavyweight, and they'll all end up *reducing* bloat and complexity. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 15 1:12:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id A060037B66A for ; Mon, 15 May 2000 01:12:25 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id KAA45222; Mon, 15 May 2000 10:10:11 +0200 (CEST) (envelope-from des@flood.ping.uio.no) To: Ben Smithurst Cc: arch@FreeBSD.org Subject: Re: fetch(1) References: <20000514152427.Q10128@strontium.scientia.demon.co.uk> From: Dag-Erling Smorgrav Date: 15 May 2000 10:10:10 +0200 In-Reply-To: Ben Smithurst's message of "Sun, 14 May 2000 15:24:27 +0100" Message-ID: Lines: 11 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ben Smithurst writes: > It seems that fetching an FTP url via an HTTP proxy server is now > broken. Setting HTTP_PROXY=www-cache:8080 used to work for FTP too, but > it doesn't anymore. Yes, that's a documented bug in libfetch. I'll take a look at Umemoto-San's (sp?) patches. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 15 1:15:27 2000 Delivered-To: freebsd-arch@freebsd.org Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) by hub.freebsd.org (Postfix) with ESMTP id 2202F37B723 for ; Mon, 15 May 2000 01:15:24 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 12rG25-000Kfe-0K; Mon, 15 May 2000 08:15:22 +0000 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 JAA38043; Mon, 15 May 2000 09:19:49 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Mon, 15 May 2000 09:19:50 +0100 (BST) From: Doug Rabson To: Bruce Evans Cc: Amancio Hasty , arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution 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 Mon, 15 May 2000, Bruce Evans wrote: > On Sun, 14 May 2000, Doug Rabson wrote: > > > On Sat, 13 May 2000, Amancio Hasty wrote: > > > > > Hi Doug! > > > > > > Great idea!! > > > > > > Say, how you thought of how to to map a system call such as open, > > > read,write, or close to your new system call? > > > > This api is not a system call at all. Its a new facility for use inside > > the kernel. > > Doesn't the "a" in api stand for "application"? It does but I always felt that the meaning of the word "application" was pretty loose... -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 15 1:16:22 2000 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 9585837B9A0 for ; Mon, 15 May 2000 01:16:18 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id KAA45274; Mon, 15 May 2000 10:16:06 +0200 (CEST) (envelope-from des@flood.ping.uio.no) To: Hajimu UMEMOTO (=?iso-2022-jp?b?GyRCR19LXBsoQiAbJEJIJRsoQg==?=) Cc: ben@scientia.demon.co.uk, arch@FreeBSD.org Subject: Re: fetch(1) References: <20000514152427.Q10128@strontium.scientia.demon.co.uk> <200005141931.e4EJVwF65961@peace.mahoroba.org> From: Dag-Erling Smorgrav Date: 15 May 2000 10:16:05 +0200 In-Reply-To: Hajimu UMEMOTO's message of "Mon, 15 May 2000 04:31:58 +0900 (JST)" Message-ID: Lines: 23 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hajimu UMEMOTO ($BG_K\(B $BH%(B) writes: > Index: libfetch/fetch.c > diff -u libfetch/fetch.c.orig libfetch/fetch.c > --- libfetch/fetch.c.orig Fri May 12 01:35:25 2000 > +++ libfetch/fetch.c Mon May 15 04:02:11 2000 > @@ -69,13 +69,18 @@ > FILE * > fetchGet(struct url *URL, char *flags) > { > + int direct = (flags && strchr(flags, 'd')); > + Please separate the initialization from the declaration: int direct; direct = (flags && strchr(flags, 'd')); The rest is fine. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 15 1:36:43 2000 Delivered-To: freebsd-arch@freebsd.org Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) by hub.freebsd.org (Postfix) with ESMTP id D0D8037B71E for ; Mon, 15 May 2000 01:36:27 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 12rGMR-000MGr-0K; Mon, 15 May 2000 08:36:24 +0000 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 JAA62431; Mon, 15 May 2000 09:40:44 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Mon, 15 May 2000 09:40:44 +0100 (BST) From: Doug Rabson To: Chuck Paterson Cc: Arun Sharma , freebsd-arch@freebsd.org Subject: Re: A new api for asynchronous task execution In-Reply-To: <200005141731.LAA04793@berserker.bsdi.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, 14 May 2000, Chuck Paterson wrote: > While writing up this I noticed a trivial bug > > taskqueue_enqueue(struct taskqueue *queue, struct task *task) > { > int s = splhigh(); > > /* > * Count multiple enqueues. > */ > if (task->pending) { > task->pending++; > return; <---- really need a splx before this Well spotted, thanks. > } > > > } > }I agree that the queue should have a mutex to protect itself. Since we > }haven't finalised the api for mutex locking (we will almost certainly use > }the BSD/OS one), I can't add anything yet but I will when the new SMP > }work starts. > > FYI, the current BSD/OS mutex's have a string associated > with them, ie there name. This name is used for debugging (checking > lock order) and perhaps for blowing locks open at panic time. > Mutex's which aren't part of a group of a unique name, an example > of this might be "ipqlock". For mutex's which are all really the > same they share the same name such as "vnode interlock". There is > also the issue of what flags are passed in to initialize the mutex, > and for that matter flags used in acquiring the mutex. I guess I > should for now just point out some of the issues. > > 1) It would be useful to have meaningful name associated with > a mutex when initializing the mutex associated with a taskqueue. > > 2) There are flags needed with initializing the mutex associated > with a taskqueue. > > 3) When acquiring the mutex associated with a queue it wants to > in general not be of type M_SPIN, but sometimes it will. This makes sense. I didn't think too hard about the needs of mtx_init() when writing this but it should work to add these arguments to taskqueue_init(). > > 4) As proposed now the mutex protecting the queue often does not > want to be held while the enqueueing function is called. This is > particularly true if the enqueueing function may cause an immediate > context switch. Right. In the spl version similarly, I don't want to call the task at splhigh(). > > 5) Even the taskqueue_run really wants to just know what > type of mutex is present. > > In some ways the implementation of taskqueue_enqueue() is > not as important to get right from the start as the calling sequence > to it. There are almost certainly going to be lots more users of > the swi taskqueue than anything else and changing the few actual > implementation of the enqueuer function and init function seem like > not a big deal. Thats my view exactly. I want to fix the calling convention of taskqueue_enqueue() and the layout of struct task since those are the main features which most users of the api are exposed to. The implementation details of struct taskqueue are less important. In fact, I think it should be possible to hide the definition of struct taskqueue completely by moving it out of the header. That would isolate any callers from implementation changes quite neatly. > > I have included just some sketches of how you could deal > with some of this. Just something to think about > > The following is very slightly slower because the type of > mutex is not known at compile times, but it makes it possible > to not have to totally change to model. Thanks for spending the time to look at this stuff in detail. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 15 1:40:39 2000 Delivered-To: freebsd-arch@freebsd.org Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by hub.freebsd.org (Postfix) with ESMTP id C35CF37B5F7; Mon, 15 May 2000 01:40:26 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 12rGQF-0006te-0A; Mon, 15 May 2000 08:40:19 +0000 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 JAA64313; Mon, 15 May 2000 09:44:41 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Mon, 15 May 2000 09:44:41 +0100 (BST) From: Doug Rabson To: Mike Smith Cc: Nick Hibma , arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution In-Reply-To: <200005141948.MAA09452@mass.cdrom.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, 14 May 2000, Mike Smith wrote: > > > > Any sense in having statically-initialised task queues? > > > > > > > > TASK_QUEUE(name); > > > > > > I thought of this but couldn't quite decide if it was useful. I don't > > > expect there to be many queues around. To start with, there will only be > > > the SWI queue. > > > > I think it is a valid point. Otherwise you might get an increased number > > of modules that require init on load. This functionality is bound to > > become very useful in cases where you want to execute things > > in a batched fashion. > > > > Apart from that, IMHO it should be > > > > TASK_QUEUE(name, enqueue_fn) > > > > to match taskqueue_init. > > Indeed. I've actually been thinking about this for a little longer, and > there are a couple of things that come to mind. > > We have a number of different callout list implementation kicking around > in the kernel at the moment; > > - the EVENTHANDLER stuff > - the optimised callout list handling in kern_timeout.c > - a few ad-hoc leftovers like config_intrhook that should have been > EVENTHANDLERed but weren't > > I don't think that kern_timeout's domain should be encroached upon, but > all of the rest of this is still worth subsuming if you're going to > produce a "better" API. > > To do that, you really only need a few extra things: > > - The ability to search for a taskqueue by name (I really don't like the > hard binding that's required by having the linker do this). > > - Some more flexibility in the enqueueing of tasks, particularly the > ability to specify a priority so that tasks on the queue are executed > in an ordered fashion. > > - Static taskqueue initialisers. > > None of these are particularly heavyweight, and they'll all end up > *reducing* bloat and complexity. I do hope to be able to replace at least some of these pieces. I like the idea of a priority sorted list of tasks, probably using a priority field in struct task. As Chuck noted, a queue name will be useful for initialising SMP mutexes so I'll add that to taskqueue_init(). It should be easy to leverage that into something like taskqueue_find(). -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 15 1:58:52 2000 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 0B4EE37B52A for ; Mon, 15 May 2000 01:58:47 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id KAA45412; Mon, 15 May 2000 10:58:41 +0200 (CEST) (envelope-from des@flood.ping.uio.no) To: Hajimu UMEMOTO (=?iso-2022-jp?b?GyRCR19LXBsoQiAbJEJIJRsoQg==?=) Cc: arch@FreeBSD.ORG Subject: Re: fetch(1) References: <200005122016.e4CKGtF38185@peace.mahoroba.org> From: Dag-Erling Smorgrav Date: 15 May 2000 10:58:40 +0200 In-Reply-To: Hajimu UMEMOTO's message of "Sat, 13 May 2000 05:16:55 +0900 (JST)" Message-ID: Lines: 15 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hajimu UMEMOTO ($BG_K\(B $BH%(B) writes: > I wrote IPv6 support part of it and now testing. > > http://www.imasy.or.jp/~ume/ipv6/FreeBSD/libfetch-ipv6.diff.gz > http://www.imasy.or.jp/~ume/ipv6/FreeBSD/fetch-20000508-ipv6.diff The patches look fine - I don't have enough experience with IPv6 to judge their technical merits, but they're relatively low-impact and I assume that you know what you're doing. If you commit the libfetch part of the patches, I'll merge the fetch part and put up a new tarball. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 15 2:10: 2 2000 Delivered-To: freebsd-arch@freebsd.org Received: from hitpro.hitachi.co.jp (hitpro.hitachi.co.jp [133.145.224.7]) by hub.freebsd.org (Postfix) with ESMTP id 17C2937B725 for ; Mon, 15 May 2000 02:09:49 -0700 (PDT) (envelope-from ume@bisd.hitachi.co.jp) Received: from bisdgw.bisd.hitachi.co.jp by hitpro.hitachi.co.jp (8.9.3/3.7W-hitpro) id SAA19917; Mon, 15 May 2000 18:07:46 +0900 (JST) Received: from plum.ssr.bisd.hitachi.co.jp by bisdgw.bisd.hitachi.co.jp (8.9.3+3.2W/3.7W-bisdgw) with ESMTP id SAA21570; Mon, 15 May 2000 18:07:45 +0900 (JST) (envelope-from ume@bisd.hitachi.co.jp) Received: from localhost (IDENT:LahYeUN8U+PFQ5Bmoz5cN+bUQVO91+hV@localhost [127.0.0.1]) by plum.ssr.bisd.hitachi.co.jp (8.10.1/3.7W-plum) with ESMTP id e4F97ix48733; Mon, 15 May 2000 18:07:45 +0900 (JST) (envelope-from ume@bisd.hitachi.co.jp) Message-Id: <200005150907.e4F97ix48733@plum.ssr.bisd.hitachi.co.jp> To: des@flood.ping.uio.no Cc: ben@scientia.demon.co.uk, arch@FreeBSD.org Subject: Re: fetch(1) From: Hajimu UMEMOTO (=?iso-2022-jp?B?GyRCR19LXBsoQiAbJEJIJRsoQg==?=) In-Reply-To: References: <20000514152427.Q10128@strontium.scientia.demon.co.uk> <200005141931.e4EJVwF65961@peace.mahoroba.org> X-Mailer: xcite1.20> Mew version 1.94.2 on XEmacs 21.1 (Bryce Canyon) X-PGP-Fingerprint: D3 3D D3 54 88 13 DE 22 3F 31 C4 4D A1 08 84 7B X-PGP-Public-Key: http://www.imasy.org/~ume/ume@bisd.hitachi.co.jp.asc X-URL: http://www.imasy.org/~ume/ X-OS: FreeBSD 4.0-STABLE Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 15 May 2000 18:07:44 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 18 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> On 15 May 2000 10:16:05 +0200 >>>>> des@flood.ping.uio.no (Dag-Erling Smorgrav) said: des> Please separate the initialization from the declaration: des> int direct; des> direct = (flags && strchr(flags, 'd')); des> The rest is fine. Thanks. I changed around it and committed. -- Hajimu UMEMOTO @ Business Solution System Development Div., Hitachi Ltd. E-Mail: ume@bisd.hitachi.co.jp ume@mahoroba.org ume@FreeBSD.org URL: http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 15 9:55:25 2000 Delivered-To: freebsd-arch@freebsd.org Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by hub.freebsd.org (Postfix) with ESMTP id 3532637BB1B; Mon, 15 May 2000 09:55:10 -0700 (PDT) (envelope-from n_hibma@calcaphon.com) Received: from calcaphon.demon.co.uk ([193.237.19.5] helo=bluebottle.qubesoft.com) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 12rO8r-000DtV-0A; Mon, 15 May 2000 16:54:53 +0000 Received: from henny.webweaving.org (henny.qubesoft.com [192.168.1.5]) by bluebottle.qubesoft.com (8.9.3/8.9.1) with ESMTP id RAA38632; Mon, 15 May 2000 17:54:49 +0100 (BST) (envelope-from n_hibma@calcaphon.com) Received: from localhost (localhost [127.0.0.1]) by henny.webweaving.org (8.9.3/8.9.3) with ESMTP id LAA82369; Mon, 15 May 2000 11:20:32 +0100 (BST) (envelope-from n_hibma@calcaphon.com) Date: Mon, 15 May 2000 11:20:32 +0100 (BST) From: Nick Hibma X-Sender: n_hibma@localhost Reply-To: Nick Hibma To: Mike Smith Cc: Doug Rabson , arch@freebsd.org Subject: Re: A new api for asynchronous task execution In-Reply-To: <200005141948.MAA09452@mass.cdrom.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 > We have a number of different callout list implementation kicking around > in the kernel at the moment; > > - the EVENTHANDLER stuff > - the optimised callout list handling in kern_timeout.c > - a few ad-hoc leftovers like config_intrhook that should have been > EVENTHANDLERed but weren't - The delayed attach for disk devices - The after interrupts-have-been-switched-on task queue None of these need any functionality above the provided stuff. > - The ability to search for a taskqueue by name (I really don't like the > hard binding that's required by having the linker do this). Good idea. This can easily be implemented on what is there now. (struct taskqueue *) taskqueue_find(const char *name) > - Some more flexibility in the enqueueing of tasks, particularly the > ability to specify a priority so that tasks on the queue are executed > in an ordered fashion. It would be useful in the case of attachment of drives (giving priority to the fixed controllers over for example the USB ones (USB Zip drives not stealing the da0 entry when attached without wiring things down, John Baldwin reported this one). > - Static taskqueue initialisers. > > None of these are particularly heavyweight, and they'll all end up > *reducing* bloat and complexity. I agree. Doing it right the first time. Nick -- n_hibma@webweaving.org n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 15 10:24:29 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id B223137BB7F; Mon, 15 May 2000 10:24:20 -0700 (PDT) (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.3) with ESMTP id TAA06224; Mon, 15 May 2000 19:24:14 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Nick Hibma Cc: Mike Smith , Doug Rabson , arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution In-reply-to: Your message of "Mon, 15 May 2000 11:20:32 BST." Date: Mon, 15 May 2000 19:24:14 +0200 Message-ID: <6222.958411454@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Nick Hibma wri tes: >> We have a number of different callout list implementation kicking around >> in the kernel at the moment; >> >> - the EVENTHANDLER stuff >> - the optimised callout list handling in kern_timeout.c >> - a few ad-hoc leftovers like config_intrhook that should have been >> EVENTHANDLERed but weren't > >- The delayed attach for disk devices >- The after interrupts-have-been-switched-on task queue Actually both of these can be done much more cleanly by moving all driver probe/attach to a later point where interrupts are enabled. This is needed functionality for all pccard, cardbus, and all other hotswap kind of hardware anyway. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 15 11:26:24 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.cdrom.com (adsl-63-202-176-114.dsl.snfc21.pacbell.net [63.202.176.114]) by hub.freebsd.org (Postfix) with ESMTP id E4F8737B655; Mon, 15 May 2000 11:25:57 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id LAA13075; Mon, 15 May 2000 11:26:26 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200005151826.LAA13075@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Nick Hibma Cc: Mike Smith , Doug Rabson , arch@freebsd.org Subject: Re: A new api for asynchronous task execution In-reply-to: Your message of "Mon, 15 May 2000 11:20:32 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 May 2000 11:26:26 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > We have a number of different callout list implementation kicking around > > in the kernel at the moment; > > > > - the EVENTHANDLER stuff > > - the optimised callout list handling in kern_timeout.c > > - a few ad-hoc leftovers like config_intrhook that should have been > > EVENTHANDLERed but weren't > > - The delayed attach for disk devices > - The after interrupts-have-been-switched-on task queue Er, that's config_intrhook. > None of these need any functionality above the provided stuff. That's not true; several users of the above require the ability to be sorted onto their task queue. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 15 21:43:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id A3DE137B606 for ; Mon, 15 May 2000 21:43:12 -0700 (PDT) (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 VAA16776; Mon, 15 May 2000 21:43:11 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id VAA80661; Mon, 15 May 2000 21:43:11 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Mon, 15 May 2000 21:43:11 -0700 (PDT) Message-Id: <200005160443.VAA80661@vashon.polstra.com> To: obrien@NUXI.com Subject: Re: .s -> .S filename change in /sys In-Reply-To: <20000509094758.A45336@dragon.nuxi.com> References: <20000509094758.A45336@dragon.nuxi.com> Organization: Polstra & Co., Seattle, WA Cc: arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This thread seems to have languished without anybody declaring victory. As far as I can tell I was just about the only voice in opposition to the idea, so I'll concede defeat at this point. There was a bit more controversy over whether to rename all the files or just the ones that actually use the preprocessor. If there is to be any renaming at all, I hope it will be done universally to all the files, except perhaps the ones in "src/sys/boot". John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 16 1: 9:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by hub.freebsd.org (Postfix) with ESMTP id 3CDE237B7A9; Tue, 16 May 2000 01:09:28 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 12rcPb-0001kY-0A; Tue, 16 May 2000 08:09:09 +0000 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 JAA58282; Tue, 16 May 2000 09:13:45 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Tue, 16 May 2000 09:13:30 +0100 (BST) From: Doug Rabson To: Mike Smith Cc: Nick Hibma , arch@freebsd.org Subject: Re: A new api for asynchronous task execution In-Reply-To: <200005151826.LAA13075@mass.cdrom.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, 15 May 2000, Mike Smith wrote: > > > We have a number of different callout list implementation kicking around > > > in the kernel at the moment; > > > > > > - the EVENTHANDLER stuff > > > - the optimised callout list handling in kern_timeout.c > > > - a few ad-hoc leftovers like config_intrhook that should have been > > > EVENTHANDLERed but weren't > > > > - The delayed attach for disk devices > > - The after interrupts-have-been-switched-on task queue > > Er, that's config_intrhook. > > > None of these need any functionality above the provided stuff. > > That's not true; several users of the above require the ability to be > sorted onto their task queue. I'm planning to add that today along with a few other bits and pieces. I'll post an updated manpage this evening. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 16 4:15: 3 2000 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by hub.freebsd.org (Postfix) with ESMTP id EAF8D37B84D; Tue, 16 May 2000 04:15:00 -0700 (PDT) (envelope-from n_hibma@calcaphon.com) Received: from calcaphon.demon.co.uk ([193.237.19.5] helo=bluebottle.qubesoft.com) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 12rfJB-0008vo-0W; Tue, 16 May 2000 12:14:42 +0100 Received: from henny.webweaving.org (henny.qubesoft.com [192.168.1.5]) by bluebottle.qubesoft.com (8.9.3/8.9.1) with ESMTP id MAA15207; Tue, 16 May 2000 12:14:34 +0100 (BST) (envelope-from n_hibma@calcaphon.com) Received: from localhost (localhost [127.0.0.1]) by henny.webweaving.org (8.9.3/8.9.3) with ESMTP id KAA84149; Tue, 16 May 2000 10:54:22 +0100 (BST) (envelope-from n_hibma@calcaphon.com) Date: Tue, 16 May 2000 10:54:22 +0100 (BST) From: Nick Hibma X-Sender: n_hibma@localhost Reply-To: Nick Hibma To: Mike Smith Cc: Doug Rabson , arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution In-Reply-To: <200005151826.LAA13075@mass.cdrom.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 > > > - the EVENTHANDLER stuff > > > - the optimised callout list handling in kern_timeout.c > > > - a few ad-hoc leftovers like config_intrhook that should have been > > > EVENTHANDLERed but weren't > > > > - The delayed attach for disk devices > > - The after interrupts-have-been-switched-on task queue > > Er, that's config_intrhook. yes, but I'd like to consolidate things onto one maybe two API's instead of maintaining callback list in multiple places. > > None of these need any functionality above the provided stuff. > > That's not true; several users of the above require the ability to be > sorted onto their task queue. Yes. nick -- n_hibma@webweaving.org n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 16 11:57:25 2000 Delivered-To: freebsd-arch@freebsd.org Received: from peace.mahoroba.org (peace.calm.imasy.or.jp [202.227.26.34]) by hub.freebsd.org (Postfix) with ESMTP id 0C07337BAE0 for ; Tue, 16 May 2000 11:57:17 -0700 (PDT) (envelope-from ume@mahoroba.org) Received: from localhost (IDENT:++HZv7OzshIb+HWEohnE2pVceH/7yGAg7f38Cd9umtJX+ffLiZYHf5QRBFsHuQrH@localhost [::1]) by peace.mahoroba.org (8.10.1/3.7W-peace) with ESMTP id e4GIqhF74521; Wed, 17 May 2000 03:52:43 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 17 May 2000 03:52:43 +0900 (JST) Message-Id: <200005161852.e4GIqhF74521@peace.mahoroba.org> To: des@flood.ping.uio.no Cc: arch@freebsd.org Subject: Re: fetch(1) In-Reply-To: References: <200005122016.e4CKGtF38185@peace.mahoroba.org> X-Mailer: xcite1.20> Mew version 1.94.2 on Emacs 20.6 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= X-PGP-Public-Key: http://www.imasy.org/~ume/publickey.asc X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.org/~ume/ X-OS: FreeBSD 5.0-CURRENT Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Hajimu UMEMOTO (=?ISO-2022-JP?B?GyRCR19LXBsoQiA=?= =?ISO-2022-JP?B?GyRCSCUbKEI=?=) X-Dispatcher: imput version 20000228(IM140) Lines: 36 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> On 15 May 2000 09:53:04 +0200 >>>>> Dag-Erling Smorgrav said: > Your fetch(1) doesn't handle content size correctly on some case. If > HTTP server doesn't reply Content-Length:, fetchStat() > (fetchStatHTTP()) doesn't return -1 and doesn't touch us.size. Then, > the value of us.size stays unknown. des> That's a bug in fetchStatHTTP(), thanks for pointing it out. You are welcome. There is one more problem. If us.size is -1 with HTTP, gotten file is shorten than original one. This change seems to fix it. Index: http.c =================================================================== RCS file: /home/ncvs/src/lib/libfetch/http.c,v retrieving revision 1.18 diff -u -r1.18 http.c --- http.c 2000/05/15 09:05:36 1.18 +++ http.c 2000/05/16 18:53:46 @@ -135,6 +135,8 @@ } else if (c->encoding == ENC_CHUNKED) { if (c->chunksize == 0) { ln = fgetln(c->real_f, &len); + if (len <= 2) + return NULL; DEBUG(fprintf(stderr, "\033[1m_http_fillbuf(): new chunk: " "%*.*s\033[m\n", (int)len-2, (int)len-2, ln)); sscanf(ln, "%x", &(c->chunksize)); -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 16 13: 6: 2 2000 Delivered-To: freebsd-arch@freebsd.org Received: from peace.mahoroba.org (peace.calm.imasy.or.jp [202.227.26.34]) by hub.freebsd.org (Postfix) with ESMTP id C197A37BB80 for ; Tue, 16 May 2000 13:05:57 -0700 (PDT) (envelope-from ume@mahoroba.org) Received: from localhost (IDENT:swDsu/GOFUZmCyEOJ0KRa8dLopoP3e4on2+sDkUZSFSnrHgIaWAtiVnO+b3ubINH@localhost [::1]) by peace.mahoroba.org (8.10.1/3.7W-peace) with ESMTP id e4GK1bF75342; Wed, 17 May 2000 05:01:37 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 17 May 2000 05:01:37 +0900 (JST) Message-Id: <200005162001.e4GK1bF75342@peace.mahoroba.org> To: des@flood.ping.uio.no Cc: arch@freebsd.org Subject: Re: fetch(1) In-Reply-To: <200005161852.e4GIqhF74521@peace.mahoroba.org> References: <200005122016.e4CKGtF38185@peace.mahoroba.org> <200005161852.e4GIqhF74521@peace.mahoroba.org> X-Mailer: xcite1.20> Mew version 1.94.2 on Emacs 20.6 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= X-PGP-Public-Key: http://www.imasy.org/~ume/publickey.asc X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.org/~ume/ X-OS: FreeBSD 5.0-CURRENT Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit From: Hajimu UMEMOTO (=?ISO-2022-JP?B?GyRCR19LXBsoQiA=?= =?ISO-2022-JP?B?GyRCSCUbKEI=?=) X-Dispatcher: imput version 20000228(IM140) Lines: 40 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>> Wed, 17 May 2000 03:52:43 +0900 (JST) $B$N9o$K!V$&$a!W!"$9$J$o$A(B >>> Hajimu UMEMOTO ($BG_K\(B $BH%(B) $B;a[)$/(B >>>>> On 15 May 2000 09:53:04 +0200 >>>>> Dag-Erling Smorgrav said: ume> There is one more problem. If us.size is -1 with HTTP, gotten file is ume> shorten than original one. One more. Fetch to ftp.openbsd.org fails with `999 Protocol error'. Ftp.openbsd.org seems to return '230 ' without any trailing message. libfetch: Info: sending 'PASS ftp' libfetch: Info: got reply '230- Guest login ok, access restrictions apply.' libfetch: Info: got reply '230- Local time is: Tue May 16 13:45:33 2000' libfetch: Info: got reply '230 ' libfetch: Protocol error (999 Protocol error) Index: ftp.c =================================================================== RCS file: /home/ncvs/src/lib/libfetch/ftp.c,v retrieving revision 1.19 diff -u -r1.19 ftp.c --- ftp.c 2000/05/15 08:24:58 1.19 +++ ftp.c 2000/05/16 19:57:02 @@ -120,7 +120,7 @@ #endif } while (isftpinfo(last_reply)); - while (lr_length && isspace(last_reply[lr_length-1])) + while (lr_length && isspace(last_reply[lr_length-1]) && lr_length > 4) lr_length--; last_reply[lr_length] = 0; -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 16 13:44:38 2000 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by hub.freebsd.org (Postfix) with ESMTP id 9BE4F37B8F3 for ; Tue, 16 May 2000 13:44:14 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by anchor-post-30.mail.demon.net with esmtp (Exim 2.12 #1) id 12roC9-000DcX-0U for arch@freebsd.org; Tue, 16 May 2000 21:44:01 +0100 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 VAA05041 for ; Tue, 16 May 2000 21:48:45 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Tue, 16 May 2000 21:48:21 +0100 (BST) From: Doug Rabson To: arch@freebsd.org Subject: A new api for asynchronous task execution (2) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-105894769-958510101=:47945" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-105894769-958510101=:47945 Content-Type: TEXT/PLAIN; charset=US-ASCII Ok, after the last set of feedback, I have updated the design somewhat. This is the latest manpage and I have attached a sample implementation (not thoroughly tested). TASKQUEUE(9) FreeBSD Kernel Developer's Manual TASKQUEUE(9) NAME taskqueue - asynchronous task execution SYNOPSIS #include #include #include typedef void (*task_fn)(void *context, int pending); typedef void (*taskqueue_enqueue_fn)(void *context); struct task { STAILQ_ENTRY(task) link; /* link for queue */ int pending; /* count times task is queued */ task_fn func; /* task handler */ void *context; /* argument for handler */ }; #define TQ_DEF 0 /* use blocking mutex */ #define TQ_SPIN 1 /* use spin mutex */ void taskqueue_init(struct taskqueue *queue, const char *name, int flags, taskqueue_enqueue_fn enqueue, void *context) struct taskqueue * taskqueue_find(const char *name) void taskqueue_enqueue(struct taskqueue *queue, struct task *task) void taskqueue_run(struct taskqueue *queue) DESCRIPTION These functions provide a simple interface for asynchronous execution of code. Before a queue can be used, it must first be initialised with taskqueue_init(). The arguments to taskqueue_init() include a name which should be unique, a flag which specifies the type of SMP mutex used to protect the queue and a function which is called from taskqueue_enqueue() when a task is added to the queue to allow the queue to arrange to be run later (for instance by scheduling a software interrupt or waking a kernel thread). The function taskqueue_free() should be used to remove the queue from the global list of queues. Any tasks which are on the queue will be executed at this time. The system maintains a list of all queues which can be searched using taskqueue_find(). The first queue whose name matches is returned, other- wise NULL. To add a task to the list of tasks queued on a taskqueue, call taskqueue_enqueue() with pointers to the queue and task. If the task's pending field is zero, the task is added to the end of the list and pending is set to one, otherwise, pending is incremented. Enqueueing a task does not perform any memory allocation which makes it suitable for calling from an interrupt handler. To execute all the tasks on a queue, call taskqueue_run(). When a task is executed, first it is removed from the queue, the value of pending is recorded and the field is zeroed. The function func from the task struc- ture is called with the value of the field context its first argument and the value of pending as its second argument. The system provides a global taskqueue, taskqueue_swi, which is run via a software interrupt mechanism. To use this queue, call taskqueue_enqueue() with the value of the global variable taskqueue_swi. The queue will be run at splsofttq(). This queue can be used, for instance, for implementing interrupt handlers which must perform a significant amount of processing in the handler. The hardware interrupt handler would perform minimal processing of the interrupt and then enqueue a task to finish the work. This reduces the amount of time spent with interrupts disabled to a minimum. HISTORY This interface first appeared in FreeBSD 5.0. There is a similar facili- ty called tqueue in the Linux kernel. AUTHORS This man page was written by Doug Rabson. FreeBSD May 12, 2000 2 -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 --0-105894769-958510101=:47945 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="subr_taskqueue.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="subr_taskqueue.c" LyotDQogKiBDb3B5cmlnaHQgKGMpIDIwMDAgRG91ZyBSYWJzb24NCiAqIEFs bCByaWdodHMgcmVzZXJ2ZWQuDQogKg0KICogUmVkaXN0cmlidXRpb24gYW5k IHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRo b3V0DQogKiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQg dGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMNCiAqIGFyZSBtZXQ6DQog KiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRh aW4gdGhlIGFib3ZlIGNvcHlyaWdodA0KICogICAgbm90aWNlLCB0aGlzIGxp c3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVy Lg0KICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3Qg cmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQNCiAqICAgIG5vdGljZSwg dGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlz Y2xhaW1lciBpbiB0aGUNCiAqICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90 aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24u DQogKg0KICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQVVU SE9SIEFORCBDT05UUklCVVRPUlMgYGBBUyBJUycnIEFORA0KICogQU5ZIEVY UFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBO T1QgTElNSVRFRCBUTywgVEhFDQogKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0Yg TUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIg UFVSUE9TRQ0KICogQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFM TCBUSEUgQVVUSE9SIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUNCiAqIEZP UiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwg RVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMDQogKiBEQU1BR0VTIChJTkNM VURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VC U1RJVFVURSBHT09EUw0KICogT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBE QVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pDQog KiBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJ VFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVA0KICogTElBQklMSVRZ LCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0Up IEFSSVNJTkcgSU4gQU5ZIFdBWQ0KICogT1VUIE9GIFRIRSBVU0UgT0YgVEhJ UyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElU WSBPRg0KICogU1VDSCBEQU1BR0UuDQogKg0KICoJJEZyZWVCU0QkDQogKi8N Cg0KI2luY2x1ZGUgPHN5cy9wYXJhbS5oPg0KI2luY2x1ZGUgPHN5cy9xdWV1 ZS5oPg0KI2luY2x1ZGUgPHN5cy9zeXN0bS5oPg0KI2luY2x1ZGUgPHN5cy9r ZXJuZWwuaD4NCiNpbmNsdWRlIDxzeXMvdGFza3F1ZXVlLmg+DQojaW5jbHVk ZSA8c3lzL2ludGVycnVwdC5oPg0KI2luY2x1ZGUgPHN5cy9tYWxsb2MuaD4N CiNpbmNsdWRlIDxtYWNoaW5lL2lwbC5oPg0KDQpNQUxMT0NfREVGSU5FKE1f VEFTS1FVRVVFLCAidGFza3F1ZXVlIiwgIlRhc2sgUXVldWVzIik7DQoNCnN0 YXRpYyBTVEFJTFFfSEVBRCh0YXNrcXVldWVfbGlzdCwgdGFza3F1ZXVlKSB0 YXNrcXVldWVfcXVldWVzOw0KDQpzdHJ1Y3QgdGFza3F1ZXVlIHsNCglTVEFJ TFFfRU5UUlkodGFza3F1ZXVlKQlsaW5rOw0KCVNUQUlMUV9IRUFEKCwgdGFz aykJcXVldWU7DQoJY29uc3QgY2hhcgkJKm5hbWU7DQoJdGFza3F1ZXVlX2Vu cXVldWVfZm4JZW5xdWV1ZTsNCgl2b2lkCQkJKmNvbnRleHQ7DQp9Ow0KDQpz dHJ1Y3QgdGFza3F1ZXVlICoNCnRhc2txdWV1ZV9jcmVhdGUoY29uc3QgY2hh ciAqbmFtZSwgaW50IGZsYWdzLA0KCQkgdGFza3F1ZXVlX2VucXVldWVfZm4g ZW5xdWV1ZSwgdm9pZCAqY29udGV4dCkNCnsNCglzdHJ1Y3QgdGFza3F1ZXVl ICpxdWV1ZTsNCg0KCXF1ZXVlID0gbWFsbG9jKHNpemVvZihzdHJ1Y3QgdGFz a3F1ZXVlKSwgTV9UQVNLUVVFVUUsIE1fTk9XQUlUKTsNCglpZiAoIXF1ZXVl KQ0KCQlyZXR1cm4gMDsNCg0KCVNUQUlMUV9JTlNFUlRfVEFJTCgmdGFza3F1 ZXVlX3F1ZXVlcywgcXVldWUsIGxpbmspOw0KCVNUQUlMUV9JTklUKCZxdWV1 ZS0+cXVldWUpOw0KCXF1ZXVlLT5uYW1lID0gbmFtZTsNCglxdWV1ZS0+ZW5x dWV1ZSA9IGVucXVldWU7DQoJcXVldWUtPmNvbnRleHQgPSBjb250ZXh0Ow0K DQoJcmV0dXJuIHF1ZXVlOw0KfQ0KDQp2b2lkDQp0YXNrcXVldWVfZnJlZShz dHJ1Y3QgdGFza3F1ZXVlICpxdWV1ZSkNCnsNCglpbnQgcyA9IHNwbGhpZ2go KTsNCgl0YXNrcXVldWVfcnVuKHF1ZXVlKTsNCglTVEFJTFFfUkVNT1ZFKCZ0 YXNrcXVldWVfcXVldWVzLCBxdWV1ZSwgdGFza3F1ZXVlLCBsaW5rKTsNCglz cGx4KHMpOw0KDQoJZnJlZShxdWV1ZSwgTV9UQVNLUVVFVUUpOw0KfQ0KDQpz dHJ1Y3QgdGFza3F1ZXVlICoNCnRhc2txdWV1ZV9maW5kKGNvbnN0IGNoYXIg Km5hbWUpDQp7DQoJc3RydWN0IHRhc2txdWV1ZSAqcXVldWU7DQoNCglTVEFJ TFFfRk9SRUFDSChxdWV1ZSwgJnRhc2txdWV1ZV9xdWV1ZXMsIGxpbmspDQoJ CWlmICghc3RyY21wKHF1ZXVlLT5uYW1lLCBuYW1lKSkNCgkJCXJldHVybiBx dWV1ZTsNCglyZXR1cm4gMDsNCn0NCg0Kdm9pZA0KdGFza3F1ZXVlX2VucXVl dWUoc3RydWN0IHRhc2txdWV1ZSAqcXVldWUsIHN0cnVjdCB0YXNrICp0YXNr KQ0Kew0KCWludCBzID0gc3BsaGlnaCgpOw0KDQoJLyoNCgkgKiBDb3VudCBt dWx0aXBsZSBlbnF1ZXVlcy4NCgkgKi8NCglpZiAodGFzay0+cGVuZGluZykg ew0KCQl0YXNrLT5wZW5kaW5nKys7DQoJCXNwbHgocyk7DQoJCXJldHVybjsN Cgl9DQoJU1RBSUxRX0lOU0VSVF9UQUlMKCZxdWV1ZS0+cXVldWUsIHRhc2ss IGxpbmspOw0KCXRhc2stPnBlbmRpbmcgPSAxOw0KCWlmIChxdWV1ZS0+ZW5x dWV1ZSkNCgkJcXVldWUtPmVucXVldWUocXVldWUtPmNvbnRleHQpOw0KDQoJ c3BseChzKTsNCn0NCg0Kdm9pZA0KdGFza3F1ZXVlX3J1bihzdHJ1Y3QgdGFz a3F1ZXVlICpxdWV1ZSkNCnsNCglpbnQgczsNCglzdHJ1Y3QgdGFzayAqdGFz azsNCglpbnQgcGVuZGluZzsNCg0KCXMgPSBzcGxoaWdoKCk7DQoJd2hpbGUg KFNUQUlMUV9GSVJTVCgmcXVldWUtPnF1ZXVlKSkgew0KCQkvKg0KCQkgKiBD YXJlZnVsbHkgcmVtb3ZlIHRoZSBmaXJzdCB0YXNrIGZyb20gdGhlIHF1ZXVl IGFuZA0KCQkgKiB6ZXJvIGl0cyBwZW5kaW5nIGNvdW50Lg0KCQkgKi8NCgkJ dGFzayA9IFNUQUlMUV9GSVJTVCgmcXVldWUtPnF1ZXVlKTsNCgkJU1RBSUxR X1JFTU9WRV9IRUFEKCZxdWV1ZS0+cXVldWUsIGxpbmspOw0KCQlwZW5kaW5n ID0gdGFzay0+cGVuZGluZzsNCgkJdGFzay0+cGVuZGluZyA9IDA7DQoJCXNw bHgocyk7DQoNCgkJdGFzay0+ZnVuYyh0YXNrLT5jb250ZXh0LCBwZW5kaW5n KTsNCg0KCQlzID0gc3BsaGlnaCgpOw0KCX0NCglzcGx4KHMpOw0KfQ0KDQpz dGF0aWMgdm9pZA0KdGFza3F1ZXVlX3N3aV9lbnF1ZXVlKHZvaWQgKmNvbnRl eHQpDQp7DQoJc2V0c29mdHRxKCk7DQp9DQoNCnN0YXRpYyB2b2lkDQp0YXNr cXVldWVfc3dpX3J1bih2b2lkKQ0Kew0KCXRhc2txdWV1ZV9ydW4odGFza3F1 ZXVlX3N3aSk7DQp9DQoNClRBU0tRVUVVRV9ERUZJTkUoc3dpLCBUUV9ERUYs IHRhc2txdWV1ZV9zd2lfZW5xdWV1ZSwgMCwNCgkJIHJlZ2lzdGVyX3N3aShT V0lfVFEsIHRhc2txdWV1ZV9zd2lfcnVuKSk7DQo= --0-105894769-958510101=:47945 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="taskqueue.h" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="taskqueue.h" LyotDQogKiBDb3B5cmlnaHQgKGMpIDIwMDAgRG91ZyBSYWJzb24NCiAqIEFs bCByaWdodHMgcmVzZXJ2ZWQuDQogKg0KICogUmVkaXN0cmlidXRpb24gYW5k IHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRo b3V0DQogKiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQg dGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMNCiAqIGFyZSBtZXQ6DQog KiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRh aW4gdGhlIGFib3ZlIGNvcHlyaWdodA0KICogICAgbm90aWNlLCB0aGlzIGxp c3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVy Lg0KICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3Qg cmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQNCiAqICAgIG5vdGljZSwg dGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlz Y2xhaW1lciBpbiB0aGUNCiAqICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90 aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24u DQogKg0KICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQVVU SE9SIEFORCBDT05UUklCVVRPUlMgYGBBUyBJUycnIEFORA0KICogQU5ZIEVY UFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBO T1QgTElNSVRFRCBUTywgVEhFDQogKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0Yg TUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIg UFVSUE9TRQ0KICogQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFM TCBUSEUgQVVUSE9SIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUNCiAqIEZP UiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwg RVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMDQogKiBEQU1BR0VTIChJTkNM VURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VC U1RJVFVURSBHT09EUw0KICogT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBE QVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pDQog KiBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJ VFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVA0KICogTElBQklMSVRZ LCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0Up IEFSSVNJTkcgSU4gQU5ZIFdBWQ0KICogT1VUIE9GIFRIRSBVU0UgT0YgVEhJ UyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElU WSBPRg0KICogU1VDSCBEQU1BR0UuDQogKg0KICoJJEZyZWVCU0QkDQogKi8N Cg0KI2lmbmRlZiBfU1lTX1RBU0tRVUVVRV9IXw0KI2RlZmluZSBfU1lTX1RB U0tRVUVVRV9IXw0KDQojaWZkZWYgX0tFUk5FTA0KDQpzdHJ1Y3QgdGFza3F1 ZXVlOw0KDQovKg0KICogRWFjaCB0YXNrIGluY2x1ZGVzIGEgZnVuY3Rpb24g d2hpY2ggaXMgY2FsbGVkIGZyb20NCiAqIHRhc2txdWV1ZV9ydW4oKS4gVGhl IGZpcnN0IGFyZ3VtZW50IGlzIHRha2VuIGZyb20gdGhlICdjb250ZXh0Jw0K ICogZmllbGQgb2Ygc3RydWN0IHRhc2sgYW5kIHRoZSBzZWNvbmQgYXJndW1l bnQgaXMgYSBjb3VudCBvZiBob3cgbWFueQ0KICogdGltZXMgdGhlIHRhc2sg d2FzIGVucXVldWVkIGJlZm9yZSB0aGUgY2FsbCB0byB0YXNrcXVldWVfcnVu KCkuDQogKi8NCnR5cGVkZWYgdm9pZCAoKnRhc2tfZm4pKHZvaWQgKmNvbnRl eHQsIGludCBwZW5kaW5nKTsNCg0KLyoNCiAqIEEgbm90aWZpY2F0aW9uIGNh bGxiYWNrIGZ1bmN0aW9uIHdoaWNoIGlzIGNhbGxlZCBmcm9tDQogKiB0YXNr cXVldWVfZW5xdWV1ZSgpLiBUaGUgY29udGV4dCBhcmd1bWVudCBpcyBnaXZl biBpbiB0aGUgY2FsbCB0bw0KICogdGFza3F1ZXVlX2luaXQoKS4gVGhpcyBm dW5jdGlvbiB3b3VsZCBub3JtYWxseSBiZSB1c2VkIHRvIGFsbG93IHRoZQ0K ICogcXVldWUgdG8gYXJyYW5nZSB0byBydW4gaXRzZWxmIGxhdGVyIChlLmcu IGJ5IHNjaGVkdWxpbmcgYSBzb2Z0d2FyZQ0KICogaW50ZXJydXB0IG9yIHdh a2luZyBhIGtlcm5lbCB0aHJlYWQpLg0KICovDQp0eXBlZGVmIHZvaWQgKCp0 YXNrcXVldWVfZW5xdWV1ZV9mbikodm9pZCAqY29udGV4dCk7DQoNCnN0cnVj dCB0YXNrIHsNCglTVEFJTFFfRU5UUlkodGFzaykJbGluazsJLyogbGluayBm b3IgcXVldWUgKi8NCglpbnQJCQlwZW5kaW5nOyAvKiBjb3VudCB0aW1lcyB0 YXNrIGlzIHF1ZXVlZCAqLw0KCXRhc2tfZm4JCQlmdW5jOwkvKiB0YXNrIGhh bmRsZXIgKi8NCgl2b2lkCQkJKmNvbnRleHQ7IC8qIGFyZ3VtZW50IGZvciBo YW5kbGVyICovDQp9Ow0KDQovKg0KICogRmxhZ3MgZm9yIHRhc2txdWV1ZV9p bml0KCkgd2hpY2ggd2lsbCBjb250cm9sIHRoZSBwcm9wZXJ0aWVzIG9mIGEN CiAqIG11dGV4IHdpbGwgYmUgdXNlZCB0byBwcm90ZWN0IHRoZSBxdWV1ZS4N CiAqDQogKiBOb3RlOiB0aGlzIGlzIG5vdCBjdXJyZW50bHkgdXNlZCBidXQg d2lsbCBiZSB1c2VkIGluIGEgZnV0dXJlDQogKiBpbXBsZW1lbnRhdGlvbiBv ZiBTTVAuDQogKi8NCiNkZWZpbmUgVFFfREVGCQkwCS8qIHVzZSBibG9ja2lu ZyBtdXRleCAqLw0KI2RlZmluZSBUUV9TUElOCQkxCS8qIHVzZSBzcGluIG11 dGV4ICovDQoNCnN0cnVjdCB0YXNrcXVldWUJKnRhc2txdWV1ZV9jcmVhdGUo Y29uc3QgY2hhciAqbmFtZSwgaW50IGZsYWdzLA0KCQkJCQkgIHRhc2txdWV1 ZV9lbnF1ZXVlX2ZuIGVucXVldWUsDQoJCQkJCSAgdm9pZCAqY29udGV4dCk7 DQp2b2lkCQkJdGFza3F1ZXVlX2ZyZWUoc3RydWN0IHRhc2txdWV1ZSAqcXVl dWUpOw0Kc3RydWN0IHRhc2txdWV1ZQkqdGFza3F1ZXVlX2ZpbmQoY29uc3Qg Y2hhciAqbmFtZSk7DQp2b2lkCQkJdGFza3F1ZXVlX2VucXVldWUoc3RydWN0 IHRhc2txdWV1ZSAqcXVldWUsDQoJCQkJCSAgc3RydWN0IHRhc2sgKnRhc2sp Ow0Kdm9pZAkJCXRhc2txdWV1ZV9ydW4oc3RydWN0IHRhc2txdWV1ZSAqcXVl dWUpOw0KDQovKg0KICogRGVjbGFyZSBhIHJlZmVyZW5jZSB0byBhIHRhc2tx dWV1ZS4NCiAqLw0KI2RlZmluZSBUQVNLUVVFVUVfREVDTEFSRShuYW1lKQkJ CVwNCgkJCQkJCVwNCmV4dGVybiBzdHJ1Y3QgdGFza3F1ZXVlICp0YXNrcXVl dWVfIyNuYW1lDQoNCi8qDQogKiBEZWZpbmUgYW5kIGluaXRpYWxpc2UgYSB0 YXNrcXVldWUuDQogKi8NCiNkZWZpbmUgVEFTS1FVRVVFX0RFRklORShuYW1l LCBmbGFncywgZW5xdWV1ZSwgY29udGV4dCwgaW5pdCkJCVwNCgkJCQkJCQkJ CVwNCnN0cnVjdCB0YXNrcXVldWUgKnRhc2txdWV1ZV8jI25hbWU7CQkJCQlc DQoJCQkJCQkJCQlcDQpzdGF0aWMgdm9pZAkJCQkJCQkJXA0KdGFza3F1ZXVl X2RlZmluZV8jI25hbWUodm9pZCAqYXJnKQkJCQkJXA0KewkJCQkJCQkJCVwN Cgl0YXNrcXVldWVfIyNuYW1lID0JCQkJCQlcDQoJCXRhc2txdWV1ZV9jcmVh dGUoI25hbWUsIGZsYWdzLCBlbnF1ZXVlLCBjb250ZXh0KTsJXA0KCWluaXQ7 CQkJCQkJCQlcDQp9CQkJCQkJCQkJXA0KCQkJCQkJCQkJXA0KU1lTSU5JVCh0 YXNrcXVldWVfIyNuYW1lLCBTSV9TVUJfQ09ORklHVVJFLCBTSV9PUkRFUl9T RUNPTkQsCQlcDQoJdGFza3F1ZXVlX2RlZmluZV8jI25hbWUsIE5VTEwpOw0K DQovKg0KICogVGhpcyBxdWV1ZSBpcyBzZXJ2aWNlZCBieSBhIHNvZnR3YXJl IGludGVycnVwdCBoYW5kbGVyLiBUbyBlbnF1ZXVlDQogKiBhIHRhc2ssIGNh bGwgdGFza3F1ZXVlX2VucXVldWUoJnRhc2txdWV1ZV9zd2ksICZ0YXNrKS4N CiAqLw0KVEFTS1FVRVVFX0RFQ0xBUkUoc3dpKTsNCg0KI2VuZGlmIC8qIF9L RVJORUwgKi8NCg0KI2VuZGlmIC8qICFfU1lTX1RBU0tRVUVVRV9IXyAqLw0K --0-105894769-958510101=:47945-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 16 14: 5:25 2000 Delivered-To: freebsd-arch@freebsd.org Received: from cypherpunks.ai (cypherpunks.ai [209.88.68.47]) by hub.freebsd.org (Postfix) with ESMTP id 9F7D537B797 for ; Tue, 16 May 2000 14:05:21 -0700 (PDT) (envelope-from jeroen@vangelderen.org) Received: from vangelderen.org (intefix.ai [209.88.68.216]) by cypherpunks.ai (Postfix) with ESMTP id E729E78; Tue, 16 May 2000 17:05:19 -0400 (AST) Message-ID: <3921B7F7.8440441D@vangelderen.org> Date: Tue, 16 May 2000 17:04:55 -0400 From: "Jeroen C. van Gelderen" X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Doug Rabson Cc: arch@freebsd.org Subject: Re: A new api for asynchronous task execution (2) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug Rabson wrote: [...] > #define TQ_DEF 0 /* use blocking mutex */ Minor nits: If this means default, I'd rename it to TQ_DEFAULT. No need to be cryptic, preprocessors can handle legible names these days. Additionally, it may be useful to be able to explicitly specify TQ_BLOCKING in case the default ever changes. [...] > DESCRIPTION > These functions provide a simple interface for asynchronous execution of > code. > > Before a queue can be used, it must first be initialised with > taskqueue_init(). The arguments to taskqueue_init() include a name which > should be unique, [...] Wouldn't it be a good idea to enforce unique names? This might prevent some obscure bugs (KLDs creating their own queues) and shouldn't hurt as taskqueue create performance doesn't seem critical. [...] > The system provides a global taskqueue, taskqueue_swi, which is run via a > software interrupt mechanism. To use this queue, call > taskqueue_enqueue() with the value of the global variable taskqueue_swi. > The queue will be run at splsofttq(). [...] I think this should go in a separate manpage describing the SWI mechanism. SWI depends on taskqueue, not the other way around... Cheers, Jeroen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 16 14:18:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id 6140637B797 for ; Tue, 16 May 2000 14:18:26 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id PAA14892; Tue, 16 May 2000 15:18:12 -0600 (MDT) Message-Id: <200005162118.PAA14892@berserker.bsdi.com> To: "Jeroen C. van Gelderen" Cc: Doug Rabson , arch@freebsd.org Subject: Re: A new api for asynchronous task execution (2) From: Chuck Paterson Date: Tue, 16 May 2000 15:18:12 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Jeroen C. van Gelderen" wrote on: Tue, 16 May 2000 17:04:55 EDT }Doug Rabson wrote: }[...] }> #define TQ_DEF 0 /* use blocking mutex */ } }Minor nits: } }If this means default, I'd rename it to TQ_DEFAULT. No need to }be cryptic, preprocessors can handle legible names these days. } }Additionally, it may be useful to be able to explicitly specify }TQ_BLOCKING in case the default ever changes. } Just an FYI, the TQ_DEF probably came from the flag passed into the BSD/OS mutex macros which is M_DEF. These are short because the macros often get used when there is sever indenting and it is much easer to read when they don't cause a line split. Also they are used ALL over the place and after looking at the code for a few minutes there is never any doubt what they stand for. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 16 14:28:57 2000 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by hub.freebsd.org (Postfix) with ESMTP id 86BB037B88F for ; Tue, 16 May 2000 14:28:52 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by anchor-post-30.mail.demon.net with esmtp (Exim 2.12 #1) id 12rotV-000Fl6-0U; Tue, 16 May 2000 22:28:49 +0100 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 WAA05533; Tue, 16 May 2000 22:33:33 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Tue, 16 May 2000 22:33:09 +0100 (BST) From: Doug Rabson To: Nick Hibma Cc: FreeBSD Arch Mailing List Subject: Re: kobj 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, 14 May 2000, Nick Hibma wrote: > > I've had a bit of a browse through the kobj source code to see what > you'd done to the newbus stuff in order to separate the two. > > One of my main issues with it is that kobj_compile_methods panics in low > memory situations. It should return an error code / NULL. It's not > necessarily fatal if an object can't be created. I consider kobj very > similar to malloc, except that it embeds a bit of functionality in the > allocated struct. I can change it to return NULL I think. Actually, I should pass a set of malloc flags to kobj_class_compile() so that the caller can decide whether to sleep for memory. I also have some pending changes which allow the caller to pre-allocate memory for the ops cache allowing kobj to be used before malloc(9) is available. > > Second, two minor nits (or signs of brain damage on my side). You call > kobj_init twice in subr_bus.c:make_device. > And you call kobj_class_compile in subr_bus.c:root_bus_module_handler > explicitly and through kobj_init, implicitly. The second call is redundant - I have removed it. > > One last thing: KOBJ_CACHE_SIZE is by default set to 256. I find that > rather large (1kb) considering the number of methods in use currently in > newbus (per file, possibly multiple MODULES): > > 15 ./dev/iicbus/iicsmb.c > 16 ./i386/i386/nexus.c > 18 ./dev/eisa/eisaconf.c > 19 ./dev/mca/mca_bus.c > 20 ./pccard/pccard_nbk.c > 21 ./dev/pccard/pccard.c > 22 ./dev/ata/ata-all.c > 23 ./pci/pci.c > 27 ./isa/isa_common.c > 29 ./pci/pcisupport.c > > I suggest something like 120 or less (less than a power of two to make > the object fit in an allocation of a power of 2. This is a cost per-class, not per-object so perhaps a 1kb cost per-class is not too unreasonable. The size of the ops cache must be a power of two otherwise the method dispatch involves a divide which would slow it down by a factor of about 5. I found when testing that (at least on ia32), 256 was a good choice since the compiler managed to optimise the dispatch code much better. Possibly a cache size of 64 or 32 would be appropriate but this would probably slow down method dispatch by about 10-20%. > > Hope these comments are of any use. Very useful, thanks. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 16 20: 2:20 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 1322437B68A for ; Tue, 16 May 2000 20:02:17 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id NAA18079; Wed, 17 May 2000 13:01:46 +1000 Date: Wed, 17 May 2000 13:01:44 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Chuck Paterson Cc: "Jeroen C. van Gelderen" , Doug Rabson , arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution (2) In-Reply-To: <200005162118.PAA14892@berserker.bsdi.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, 16 May 2000, Chuck Paterson wrote: > Just an FYI, the TQ_DEF probably came from the flag passed > into the BSD/OS mutex macros which is M_DEF. These are short > because the macros often get used when there is sever > indenting and it is much easer to read when they don't cause > a line split. Also they are used ALL over the place and after > looking at the code for a few minutes there is never any doubt > what they stand for. Similarly for many of the other names. "queue" should usually be abbreviated as "q" or "Q", as in . Perhaps "task" should be abbreviated as "t" or "T" in more places. The names should be a little more like those in , e.g., taskq_add instead of taskqueue_enqueue and taskq_remove instead of taskqueue_free. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 16 20:21:24 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.cdrom.com (adsl-63-202-176-114.dsl.snfc21.pacbell.net [63.202.176.114]) by hub.freebsd.org (Postfix) with ESMTP id CADC537B68A for ; Tue, 16 May 2000 20:21:21 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id UAA04388; Tue, 16 May 2000 20:21:51 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200005170321.UAA04388@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Bruce Evans Cc: Chuck Paterson , "Jeroen C. van Gelderen" , Doug Rabson , arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution (2) In-reply-to: Your message of "Wed, 17 May 2000 13:01:44 +1000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 May 2000 20:21:51 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Tue, 16 May 2000, Chuck Paterson wrote: > > > Just an FYI, the TQ_DEF probably came from the flag passed > > into the BSD/OS mutex macros which is M_DEF. These are short > > because the macros often get used when there is sever > > indenting and it is much easer to read when they don't cause > > a line split. Also they are used ALL over the place and after > > looking at the code for a few minutes there is never any doubt > > what they stand for. > > Similarly for many of the other names. "queue" should usually be > abbreviated as "q" or "Q", as in . Perhaps "task" > should be abbreviated as "t" or "T" in more places. The names > should be a little more like those in , e.g., > taskq_add instead of taskqueue_enqueue and taskq_remove instead > of taskqueue_free. This is a bad precedent. It might have been a good idea fifteen or twenty years ago, when six-character symbols were all the rage, but we already have serious namespace issues in the kernel, and this doesn't help at all. Heck, "tq" is already taken (tagged queueing). (This applies to crap going into libc as well; especially new stuff. We should be using a symbol prefix that at least *tries* to keep us out of other peoples' namespaces.) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 16 21: 6:26 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id CEF1737BDEC; Tue, 16 May 2000 21:06:16 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id WAA22297; Tue, 16 May 2000 22:06:15 -0600 (MDT) Message-Id: <200005170406.WAA22297@berserker.bsdi.com> To: Mike Smith Cc: Bruce Evans , "Jeroen C. van Gelderen" , Doug Rabson , arch@freebsd.org Subject: Re: A new api for asynchronous task execution (2) From: Chuck Paterson Date: Tue, 16 May 2000 22:06:15 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG }(This applies to crap going into libc as well; especially new stuff. We } should be using a symbol prefix that at least *tries* to keep us out of } other peoples' namespaces.) This really is a very valid statement/complaint. The "M_" prefix used with the mutex stuff in BSD/OS is in common with the mbuf stuff. We, or maybe just I, though about this quite a bit before deciding to go with the M_ for mutexs. I don't know that anybody else really cared. Even though there were valid reasons for trying to keep the names short, I'm not at all sure that the right decision was reached. All of the macros start with mtx_ (mtx_enter, mtx_exit, mtx_try_enter). It may be that a global pass should be made and all the mtx "M_" should be changed to "MTX_". Comments? On a slightly related note. I see that putting prefixes on structure elements appears less common in FreeBSD than BSD/OS. Is this a conscience decision, or something that just happened because the compiler doesn't require it anymore? Actually anymore is a real long time now. Anyway, I can say with a fair amount of certainty that when it comes time to go around locking up the kernel this isn't going to be popular. When using tools like cscope/glimpse looking for foo_timeout is much more productive than just looking for timeout. There are some of these in the BSD/OS kernel and making sure all references were covered was a real pain. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 16 23:35:34 2000 Delivered-To: freebsd-arch@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id EA0C537B54A; Tue, 16 May 2000 23:35:31 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id XAA10460; Tue, 16 May 2000 23:38:02 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Chuck Paterson Cc: Mike Smith , Bruce Evans , "Jeroen C. van Gelderen" , Doug Rabson , arch@freebsd.org Subject: Re: A new api for asynchronous task execution (2) In-reply-to: Your message of "Tue, 16 May 2000 22:06:15 MDT." <200005170406.WAA22297@berserker.bsdi.com> Date: Tue, 16 May 2000 23:38:02 -0700 Message-ID: <10449.958545482@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On a slightly related note. I see that putting prefixes on > structure elements appears less common in FreeBSD than BSD/OS. Is > this a conscience decision, or something that just happened because > the compiler doesn't require it anymore? Actually anymore is a real I'd certainly say the latter. Not that one of our more motivated committers couldn't go on a renaming rampage at some point to match the current BSD/OS conventions, of course. I can see your point about it making the use of tools like cscope or global a bit easier. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 17 0: 2:21 2000 Delivered-To: freebsd-arch@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 4C2F937B9C3; Wed, 17 May 2000 00:02:17 -0700 (PDT) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id XAA14503; Tue, 16 May 2000 23:56:24 -0700 (PDT) Message-Id: <200005170656.XAA14503@implode.root.com> To: "Jordan K. Hubbard" Cc: Chuck Paterson , Mike Smith , Bruce Evans , "Jeroen C. van Gelderen" , Doug Rabson , arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution (2) In-reply-to: Your message of "Tue, 16 May 2000 23:38:02 PDT." <10449.958545482@localhost> From: David Greenman Reply-To: dg@root.com Date: Tue, 16 May 2000 23:56:24 -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> On a slightly related note. I see that putting prefixes on >> structure elements appears less common in FreeBSD than BSD/OS. Is >> this a conscience decision, or something that just happened because >> the compiler doesn't require it anymore? Actually anymore is a real > >I'd certainly say the latter. Not that one of our more motivated >committers couldn't go on a renaming rampage at some point to match >the current BSD/OS conventions, of course. I can see your point about >it making the use of tools like cscope or global a bit easier. This ranks right up there with the white space changes for me. I'd rather not see gratuitous structure name changes affecting hundreds of files unless they are really needed, although I certainly see your [Chuck's] point and will make a conscious effort to code this way myself in the future. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 17 7:41:12 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id C03BF37BB3D for ; Wed, 17 May 2000 07:41:09 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id IAA24145; Wed, 17 May 2000 08:41:03 -0600 (MDT) Message-Id: <200005171441.IAA24145@berserker.bsdi.com> To: Doug Rabson Subject: Sparc & api for asynchronous task execution (2) From: Chuck Paterson Cc: arch@freebsd.org Date: Wed, 17 May 2000 08:41:03 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG First I should point out that his may really be outside what this api was/is designed for. I am looking at putting the various things currently on the BSD/OS softint onto several different threads. I looked at using this code to gang together those items that want to be on the same thread. This is what really got me interested in this discussion to begin with. Here's the rub. Currently the stuff for queueing a particular software interrupt is strung together macros, where it gets handled by function calls with this interface. What really cause a problem is that the queueing often occurs at the very deepest point in the stack, say as a worst case ether_input(ip packet). This means that there will be two more stack overflow faults and two more stack underflow faults per packet on sparc to use this interface. With FreeBSD on Sparc there will only be one additional because of the ip_fastforward() check already took the stack down one. Actually this probably wants to be fixed also, the very top of ip_fastforward is short and could be a macro. I'm hoping there is no need to have ip input share a thread with anything else. If not I'm not sure what the right answer is. I really like the queue of tasks to run scheme rather than dedicated bits. I'm thinking of maybe trying to put together a macro version of the enqueueing to go with this stuff. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 17 10:23:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 111FB37B5A2 for ; Wed, 17 May 2000 10:23:27 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id KAA06361; Wed, 17 May 2000 10:23:03 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpdAAAN3aqum; Wed May 17 10:22:52 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id KAA05756; Wed, 17 May 2000 10:23:04 -0700 (MST) From: Terry Lambert Message-Id: <200005171723.KAA05756@usr05.primenet.com> Subject: Re: interface ideas for async locks? To: bright@wintelcom.net (Alfred Perlstein) Date: Wed, 17 May 2000 17:23:03 +0000 (GMT) Cc: arch@FreeBSD.ORG In-Reply-To: from "Alfred Perlstein" at Dec 21, 1999 04:41:33 AM X-Mailer: ELM [version 2.5 PL2] 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've gotten started on making async fcntl locks possible, the trick is > giving preference to async locks and having lock reservations put up > by the process that 'unblocks' the async lock. > > Anyhow, the reason for this mail is to get an idea of what type of > interface people would like for this feature. I would like to see it mirror the opportunity locking interface that SAMBA currently expects. This is similar to the NFSv3 LEASE idea. It is important to support opportunity locks; not for performance reasons, but because SAMBA is effectively a user space hosted OS, and this type of interface is necessary for supporting hosted OS vs. hosting OS coherency. In plain English, this means that SAMBA will respect locks held by UNIX applications, and vice versa. You might as well get SAMBA (and IRIX, and soon to be Linux) compatability with this interface for free. 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 Wed May 17 10:28: 9 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 4507637BCAC for ; Wed, 17 May 2000 10:28:04 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id KAA09961; Wed, 17 May 2000 10:27:27 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpdAAAZTaGrt; Wed May 17 10:27:13 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id KAA06011; Wed, 17 May 2000 10:27:40 -0700 (MST) From: Terry Lambert Message-Id: <200005171727.KAA06011@usr05.primenet.com> Subject: Re: A new api for asynchronous task execution To: dfr@nlsystems.com (Doug Rabson) Date: Wed, 17 May 2000 17:27:40 +0000 (GMT) Cc: arch@FreeBSD.ORG In-Reply-To: from "Doug Rabson" at May 12, 2000 08:44:39 PM X-Mailer: ELM [version 2.5 PL2] 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'm planning to add a new system to the kernel which should make it much > easier for drivers (especially loadable drivers) to use software > interrupts to implement split-level interrupt handlers. The api was > inspired by the Linux tqueue system but the implementation is quite > different. I would suggest that there is probably a lot to be learned from the NT split interrupt handling model, if the relative performance of NT and Solartis vs. BSD 4.4 based operating systems and Linux is any indicator. 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 Wed May 17 10:35:24 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 1B32F37BBC7 for ; Wed, 17 May 2000 10:35:16 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id KAA13575; Wed, 17 May 2000 10:34:36 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpdAAAynaqFA; Wed May 17 10:34:29 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id KAA06172; Wed, 17 May 2000 10:35:03 -0700 (MST) From: Terry Lambert Message-Id: <200005171735.KAA06172@usr05.primenet.com> Subject: Re: A new api for asynchronous task execution To: cp@bsdi.com (Chuck Paterson) Date: Wed, 17 May 2000 17:35:02 +0000 (GMT) Cc: dfr@nlsystems.com (Doug Rabson), arch@FreeBSD.ORG In-Reply-To: <200005132342.RAA01739@berserker.bsdi.com> from "Chuck Paterson" at May 13, 2000 05:42:23 PM X-Mailer: ELM [version 2.5 PL2] 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 > }The system defines specific implementations of queues which are drained at > }particular times (initially I have defined one using SWI). I want to make > }it as easy as possible to define different lightweight queues for various > }types of work. The 'enqueue' function pointer in the taskqueue structure > }defines the run policy for the queue. > > I would agree that there is no reason to change what you > have for generic queueing. But for taskqueue_swi currently > and a possibly others in the future you not only need to > queue the event you want to cause a software interrupt to occur > at the soonest reasonable time. Putting the item on the work > queue does not seem sufficient. In particular I would argue the > following should be avoided [ ... ] I partly agree with Chuck, particularly on avoiding this. But his suggestion bears a striking resemblence to priority bands in the SVR4.x streams implementations. I'd argue that this would be a mistake; in particular, it means that there is a signle band-based contention domain for insertion, deletion, and queue contents iteration, which itself is not SMP scalable. In my experience with the UnixWare 2.x (SVR4.2) kernel, the limits on scaling derive from contention. I believe that the SVR4.x/Solaris(pre 2.5) models are inherently flawed in terms of scaling, in the same way that the Solaris SLAB allocator in 2.x was inherently flawed for SMP scaling. When I say "SMP scaling", please also read "Real Time" and "kernel preemption", since they are spatially similar problems. I could see where you could abuse Chuck's "banding" suggestion in order to establish per CPU "bands" (worst case: allocate the name space for flags above bit 3 (2^32), and OR in an option based 0 CPU ID). This is, I think, a folley to be avoided. 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 Wed May 17 10:39:45 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 1EA2937BC78 for ; Wed, 17 May 2000 10:39:38 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id KAA29678; Wed, 17 May 2000 10:39:41 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAA4faa65; Wed May 17 10:39:32 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id KAA06300; Wed, 17 May 2000 10:39:19 -0700 (MST) From: Terry Lambert Message-Id: <200005171739.KAA06300@usr05.primenet.com> Subject: Re: A new api for asynchronous task execution To: dfr@nlsystems.com (Doug Rabson) Date: Wed, 17 May 2000 17:39:19 +0000 (GMT) Cc: bde@zeta.org.au (Bruce Evans), hasty@rah.star-gate.com (Amancio Hasty), arch@FreeBSD.ORG In-Reply-To: from "Doug Rabson" at May 15, 2000 09:19:50 AM X-Mailer: ELM [version 2.5 PL2] 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 > > > This api is not a system call at all. Its a new facility for use inside > > > the kernel. > > > > Doesn't the "a" in api stand for "application"? > > It does but I always felt that the meaning of the word "application" was > pretty loose... The 'p' stands for 'programming' or 'programmer', not 'program', so I don't think it's an issue. 8-p. 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 Wed May 17 10:41:44 2000 Delivered-To: freebsd-arch@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 1C79B37BC5F; Wed, 17 May 2000 10:41:34 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (hak.nat.Awfulhak.org [172.31.0.12]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id SAA06772; Wed, 17 May 2000 18:41:32 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id SAA02613; Wed, 17 May 2000 18:41:29 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200005171741.SAA02613@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: current@FreeBSD.org, arch@FreeBSD.org Cc: peter@FreeBSD.org Subject: modules Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 May 2000 18:41:29 +0100 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Sorry to whinge, but wWhat's the state of play with modules at the moment ? 1. To update things, I was under the impression that ``make buildworld buildkernel'' then ``make installworld installkernel'' was the idea. This doesn't build modules, but building from sys/compile/whatever builds another kernel... Is anybody going to finish what was started and make buildkernel/installkernel do the modules too ? 2. Installing rtc.ko (ports/emulators/rtc) gives exec format errors at boot time. 3. Building vmware2 now fails due to the move of bsd.kmod.mk and ultimately suffers from the same exec format error as rtc.ko Are there any plans to fix this stuff ? -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 17 10:46: 3 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id F00C637BA9F; Wed, 17 May 2000 10:45:57 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id KAA15132; Wed, 17 May 2000 10:45:24 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpdAAATyaWGD; Wed May 17 10:45:17 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id KAA06412; Wed, 17 May 2000 10:45:44 -0700 (MST) From: Terry Lambert Message-Id: <200005171745.KAA06412@usr05.primenet.com> Subject: Re: A new api for asynchronous task execution To: dfr@nlsystems.com (Doug Rabson) Date: Wed, 17 May 2000 17:45:44 +0000 (GMT) Cc: msmith@FreeBSD.ORG (Mike Smith), n_hibma@calcaphon.com (Nick Hibma), arch@FreeBSD.ORG In-Reply-To: from "Doug Rabson" at May 15, 2000 09:44:41 AM X-Mailer: ELM [version 2.5 PL2] 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 do hope to be able to replace at least some of these pieces. I like the > idea of a priority sorted list of tasks, probably using a priority field > in struct task. Bletch. This is a job best handled by managing insertion order, rather than by way of an explicit sort. Insertion order also keeps the structure both small and generic. > As Chuck noted, a queue name will be useful for initialising SMP mutexes > so I'll add that to taskqueue_init(). It should be easy to leverage that > into something like taskqueue_find(). I dislike the idea of explicit kernel mutex queues, as opposed to resource queues. The problem you run into is the inability to perform deadlock avoidance, which you would normally do by implying an edge between the top of the hierarchy into which you are inserting and the location into which you wish to insert (such an algorithm is order N+1 based on depth N and doing a reverse traversal in an attempt to detect a Hamiltonian cyclye introduced by the implication of the edge; short of caching the edge node, which would give you order N, but cost significantly, this is about the best possible algorithm you can get). 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 Wed May 17 10:58: 3 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.cdrom.com (adsl-63-202-176-114.dsl.snfc21.pacbell.net [63.202.176.114]) by hub.freebsd.org (Postfix) with ESMTP id 6C6B437BC74; Wed, 17 May 2000 10:58:00 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id KAA07014; Wed, 17 May 2000 10:58:43 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200005171758.KAA07014@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Terry Lambert Cc: dfr@nlsystems.com (Doug Rabson), msmith@FreeBSD.ORG (Mike Smith), n_hibma@calcaphon.com (Nick Hibma), arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution In-reply-to: Your message of "Wed, 17 May 2000 17:45:44 -0000." <200005171745.KAA06412@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 May 2000 10:58:42 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I do hope to be able to replace at least some of these pieces. I like the > > idea of a priority sorted list of tasks, probably using a priority field > > in struct task. > > Bletch. > > This is a job best handled by managing insertion order, rather than > by way of an explicit sort. Insertion order also keeps the structure > both small and generic. You specifically can't "manage insertion order", which is why the queues need to be sorted. Go look at the current problem set before making sweeping assertions like this. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 17 11:16: 2 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 0705037B8DB; Wed, 17 May 2000 11:15:57 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id LAA23539; Wed, 17 May 2000 11:15:22 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpdAAAvZaO0T; Wed May 17 11:15:13 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id LAA07310; Wed, 17 May 2000 11:15:38 -0700 (MST) From: Terry Lambert Message-Id: <200005171815.LAA07310@usr05.primenet.com> Subject: Re: A new api for asynchronous task execution To: msmith@FreeBSD.ORG (Mike Smith) Date: Wed, 17 May 2000 18:15:38 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), dfr@nlsystems.com (Doug Rabson), msmith@FreeBSD.ORG (Mike Smith), n_hibma@calcaphon.com (Nick Hibma), arch@FreeBSD.ORG In-Reply-To: <200005171758.KAA07014@mass.cdrom.com> from "Mike Smith" at May 17, 2000 10:58:42 AM X-Mailer: ELM [version 2.5 PL2] 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 do hope to be able to replace at least some of these pieces. I like the > > > idea of a priority sorted list of tasks, probably using a priority field > > > in struct task. > > > > Bletch. > > > > This is a job best handled by managing insertion order, rather than > > by way of an explicit sort. Insertion order also keeps the structure > > both small and generic. > > You specifically can't "manage insertion order", which is why the queues > need to be sorted. Go look at the current problem set before making > sweeping assertions like this. The "current problem set" or the "current implementation"? I know the current implementation can't handle it. I can probably give you references from as far back as the 1970's on why it's possible in the context of the current problem set. The DDJ article on skiplists in ~1993 (source code available from UUNET today) shows partially ordered insertion being applied to the current problem set. 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 Wed May 17 12:14:50 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.234]) by hub.freebsd.org (Postfix) with ESMTP id 13BB537BCA6; Wed, 17 May 2000 12:14:46 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id MAA00495; Wed, 17 May 2000 12:15:45 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200005171915.MAA00495@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Terry Lambert Cc: msmith@FreeBSD.ORG (Mike Smith), dfr@nlsystems.com (Doug Rabson), n_hibma@calcaphon.com (Nick Hibma), arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution In-reply-to: Your message of "Wed, 17 May 2000 18:15:38 -0000." <200005171815.LAA07310@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 May 2000 12:15:44 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > I do hope to be able to replace at least some of these pieces. I like the > > > > idea of a priority sorted list of tasks, probably using a priority field > > > > in struct task. > > > > > > Bletch. > > > > > > This is a job best handled by managing insertion order, rather than > > > by way of an explicit sort. Insertion order also keeps the structure > > > both small and generic. > > > > You specifically can't "manage insertion order", which is why the queues > > need to be sorted. Go look at the current problem set before making > > sweeping assertions like this. > > The "current problem set" or the "current implementation"? > > I know the current implementation can't handle it. > > I can probably give you references from as far back as the 1970's on > why it's possible in the context of the current problem set. > > The DDJ article on skiplists in ~1993 (source code available from > UUNET today) shows partially ordered insertion being applied to the > current problem set. Er, that's "sorting on insertion", not "managing insertion order". -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 17 13:26:59 2000 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by hub.freebsd.org (Postfix) with ESMTP id 518EB37BD0C for ; Wed, 17 May 2000 13:26:51 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 12sAP0-0003Ub-0Y; Wed, 17 May 2000 21:26:47 +0100 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 VAA26572; Wed, 17 May 2000 21:31:40 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Wed, 17 May 2000 21:31:00 +0100 (BST) From: Doug Rabson To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution In-Reply-To: <200005171727.KAA06011@usr05.primenet.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, 17 May 2000, Terry Lambert wrote: > > I'm planning to add a new system to the kernel which should make it much > > easier for drivers (especially loadable drivers) to use software > > interrupts to implement split-level interrupt handlers. The api was > > inspired by the Linux tqueue system but the implementation is quite > > different. > > I would suggest that there is probably a lot to be learned from > the NT split interrupt handling model, if the relative performance > of NT and Solartis vs. BSD 4.4 based operating systems and Linux > is any indicator. I'm not very familiar with the NT model but I seem to remember that the upper level is basically a kernel thread. The taskqueue system I am proposing would support that directly. With small changes, I think it could easily load balance between several worker threads. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 17 13:29:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net [194.217.242.41]) by hub.freebsd.org (Postfix) with ESMTP id 6B65E37BFC9; Wed, 17 May 2000 13:29:22 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1) id 12sARL-000LlV-0C; Wed, 17 May 2000 20:29:12 +0000 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 VAA26580; Wed, 17 May 2000 21:33:57 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Wed, 17 May 2000 21:33:17 +0100 (BST) From: Doug Rabson To: Terry Lambert Cc: Mike Smith , Nick Hibma , arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution In-Reply-To: <200005171745.KAA06412@usr05.primenet.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, 17 May 2000, Terry Lambert wrote: > > I do hope to be able to replace at least some of these pieces. I like the > > idea of a priority sorted list of tasks, probably using a priority field > > in struct task. > > Bletch. > > This is a job best handled by managing insertion order, rather than > by way of an explicit sort. Insertion order also keeps the structure > both small and generic. > > > > As Chuck noted, a queue name will be useful for initialising SMP mutexes > > so I'll add that to taskqueue_init(). It should be easy to leverage that > > into something like taskqueue_find(). > > I dislike the idea of explicit kernel mutex queues, as opposed to > resource queues. > > The problem you run into is the inability to perform deadlock > avoidance, which you would normally do by implying an edge between > the top of the hierarchy into which you are inserting and the > location into which you wish to insert (such an algorithm is order > N+1 based on depth N and doing a reverse traversal in an attempt to > detect a Hamiltonian cyclye introduced by the implication of the > edge; short of caching the edge node, which would give you order N, > but cost significantly, this is about the best possible algorithm > you can get). The BSD/OS mutex code includes a compile-time-selected debugging feature which automatically detects locking hierarchy violations. Anyway, using a mutex here doesn't add to locking complexity since the mutex would be exited before calling the task's callback and re-entered after. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 17 13:30:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by hub.freebsd.org (Postfix) with ESMTP id 4669237B8F1; Wed, 17 May 2000 13:30:19 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 12sASP-000KcT-0A; Wed, 17 May 2000 20:30:17 +0000 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 VAA26610; Wed, 17 May 2000 21:35:19 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Wed, 17 May 2000 21:34:40 +0100 (BST) From: Doug Rabson To: Mike Smith Cc: Terry Lambert , Nick Hibma , arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution In-Reply-To: <200005171915.MAA00495@mass.cdrom.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, 17 May 2000, Mike Smith wrote: > > > > > I do hope to be able to replace at least some of these pieces. I like the > > > > > idea of a priority sorted list of tasks, probably using a priority field > > > > > in struct task. > > > > > > > > Bletch. > > > > > > > > This is a job best handled by managing insertion order, rather than > > > > by way of an explicit sort. Insertion order also keeps the structure > > > > both small and generic. > > > > > > You specifically can't "manage insertion order", which is why the queues > > > need to be sorted. Go look at the current problem set before making > > > sweeping assertions like this. > > > > The "current problem set" or the "current implementation"? > > > > I know the current implementation can't handle it. > > > > I can probably give you references from as far back as the 1970's on > > why it's possible in the context of the current problem set. > > > > The DDJ article on skiplists in ~1993 (source code available from > > UUNET today) shows partially ordered insertion being applied to the > > current problem set. > > Er, that's "sorting on insertion", not "managing insertion order". Modulo some testing, my latest work-in-progress includes priority based sorting. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 17 13:41:51 2000 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by hub.freebsd.org (Postfix) with ESMTP id E8F2537BCD7 for ; Wed, 17 May 2000 13:41:41 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by anchor-post-30.mail.demon.net with esmtp (Exim 2.12 #1) id 12sAdQ-000JXj-0U; Wed, 17 May 2000 21:41:40 +0100 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 VAA26658; Wed, 17 May 2000 21:46:34 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Wed, 17 May 2000 21:45:55 +0100 (BST) From: Doug Rabson To: Chuck Paterson Cc: arch@freebsd.org Subject: Re: Sparc & api for asynchronous task execution (2) In-Reply-To: <200005171441.IAA24145@berserker.bsdi.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, 17 May 2000, Chuck Paterson wrote: > > First I should point out that his may really be outside > what this api was/is designed for. > > > I am looking at putting the various things currently on the > BSD/OS softint onto several different threads. I looked at using > this code to gang together those items that want to be on the same > thread. This is what really got me interested in this discussion > to begin with. > > Here's the rub. Currently the stuff for queueing > a particular software interrupt is strung together macros, where > it gets handled by function calls with this interface. What really > cause a problem is that the queueing often occurs at the very > deepest point in the stack, say as a worst case ether_input(ip > packet). This means that there will be two more stack overflow > faults and two more stack underflow faults per packet on sparc to > use this interface. With FreeBSD on Sparc there will only be one > additional because of the ip_fastforward() check already took the > stack down one. Actually this probably wants to be fixed also, the > very top of ip_fastforward is short and could be a macro. > > > I'm hoping there is no need to have ip input share a thread > with anything else. If not I'm not sure what the right answer > is. I really like the queue of tasks to run scheme rather than > dedicated bits. I'm thinking of maybe trying to put together a macro > version of the enqueueing to go with this stuff. I didn't realise that every function call involved a fault on the sparc architecture - that sounds pretty nasty. I have been trying to keep the ABI for this system as clear and simple as possible so that binary drivers written to this model are reasonable well insulated from a changing implementation. Enqueuing with a macro would require exposing at least part of the taskqueue structure which is the one most likely to change. One possibility is to specify that the first field in the taskqueue is always an STAILQ_HEAD(, task). A caller using that to enqueue directly would have to be responsible for using a mutex (or whatever) to protect the queue. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 17 13:56:27 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id C1ED437B512 for ; Wed, 17 May 2000 13:56:24 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id OAA25889; Wed, 17 May 2000 14:56:16 -0600 (MDT) Message-Id: <200005172056.OAA25889@berserker.bsdi.com> To: Doug Rabson Cc: arch@freebsd.org Subject: Re: Sparc & api for asynchronous task execution (2) From: Chuck Paterson Date: Wed, 17 May 2000 14:56:16 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG } }I didn't realize that every function call involved a fault on the sparc }architecture - that sounds pretty nasty. Actually every function call doesn't cause a fault, every time you overflow/underflow the current set of register windows causes a fault. (Perhaps what you meant). This means that calling a function from the bottom most function will cause two faults, one for going down and one eventually as you go up. This makes going up and down when you don't overflow very fast at the expense of when you add to the total depth. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 17 16: 4:53 2000 Delivered-To: freebsd-arch@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.2.163]) by hub.freebsd.org (Postfix) with ESMTP id B8A2437BAE7; Wed, 17 May 2000 16:04:45 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.13 #1) id 12sCrT-000Cf5-00; Thu, 18 May 2000 01:04:19 +0200 From: Sheldon Hearn To: Brian Somers Cc: current@FreeBSD.ORG, arch@FreeBSD.ORG, peter@FreeBSD.ORG Subject: Re: modules In-reply-to: Your message of "Wed, 17 May 2000 18:41:29 +0100." <200005171741.SAA02613@hak.lan.Awfulhak.org> Date: Thu, 18 May 2000 01:04:19 +0200 Message-ID: <48674.958604659@axl.ops.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 17 May 2000 18:41:29 +0100, Brian Somers wrote: > 1. To update things, I was under the impression that ``make buildworld > buildkernel'' then ``make installworld installkernel'' was the idea. > This doesn't build modules, but building from sys/compile/whatever > builds another kernel... Is anybody going to finish what was started > and make buildkernel/installkernel do the modules too ? The work on buildkernel/installkernel was done by different folks from the guy(s) who've moved the modules build. I was about to check in new stuff for the installkernel target when the modules stuff happened. Although the buildkernel/installkernel targets were Marcel's brainchild, I'm looking at it. Gimme some time (assuming nobody else gets stuck in there first); I've had unbelievable hassles trying to sell a car. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 18 0:58:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from skaarup.org (skaarup.org [130.228.230.140]) by hub.freebsd.org (Postfix) with ESMTP id 0DEE637B759 for ; Thu, 18 May 2000 00:58:11 -0700 (PDT) (envelope-from rasmus@gal.dk) Received: from localhost (skaarup@localhost) by skaarup.org (8.9.3/8.9.3) with ESMTP id JAA71314 for ; Thu, 18 May 2000 09:58:10 +0200 (CEST) (envelope-from rasmus@gal.dk) Date: Thu, 18 May 2000 09:58:10 +0200 (CEST) From: Rasmus Skaarup X-Sender: skaarup@skaarup.org To: freebsd-arch@freebsd.org Subject: Itanium 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 RedHat has released a alpha distribution for the 64-bit Itanium processor. http://www.zdnet.com/zdnn/stories/news/0,4586,2571379,00.html?chkpt=zdhpnews01 And SGI is on the wagon aswell. http://www.sgi.com/newsroom/press_releases/2000/may/linux-ia64.html What is the plans for FreeBSD, will there be an Itanium distro? If so, is there any time schedule? Thank you. Best regards Rasmus To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 18 1:41: 1 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.cdrom.com (adsl-63-202-177-47.dsl.snfc21.pacbell.net [63.202.177.47]) by hub.freebsd.org (Postfix) with ESMTP id 28A7637B956 for ; Thu, 18 May 2000 01:40:51 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id BAA00652 for ; Thu, 18 May 2000 01:41:58 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200005180841.BAA00652@mass.cdrom.com> Date: Thu, 18 May 2000 01:41:56 -0700 From: Mike Smith Subject: Re: Itanium Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ------- Blind-Carbon-Copy X-Mailer: exmh version 2.1.1 10/15/1999 To: Rasmus Skaarup Reply-to: hackers@freebsd.org Subject: Re: Itanium In-reply-to: Your message of "Thu, 18 May 2000 09:58:10 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 May 2000 01:41:56 -0700 From: Mike Smith (This is not the list for this question, please do not follow up here) > RedHat has released a alpha distribution for the 64-bit Itanium > processor. > > http://www.zdnet.com/zdnn/stories/news/0,4586,2571379,00.html?chkpt=zdhpnews01 > > And SGI is on the wagon aswell. > > http://www.sgi.com/newsroom/press_releases/2000/may/linux-ia64.html Yes, and Pacific Hitech have had a release out for some time. They're all members of the Trillium project (www.linuxia64.org), which has been a closed cabal for some time now. > What is the plans for FreeBSD, will there be an Itanium distro? If so, is > there any time schedule? FreeBSD doesn't have "distros", so no, there will not be an "Itanium distro". There is, however, an effort underway to port FreeBSD to the IA-64 architecture/platform being sponsored by BSDi. This is somewhat complicated by the fact that hardware is difficult to come by, but we do have a degree of support from Intel. At this point in time, there isn't a public time schedule other than "as soon as possible consistent with the production of a solid port". We're still looking for team members to fill a number of roles in this effort, by the way. - -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com ------- End of Blind-Carbon-Copy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 18 1:46:30 2000 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id 6659E37B956 for ; Thu, 18 May 2000 01:46:27 -0700 (PDT) (envelope-from paul@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1000) id 064A72B209; Thu, 18 May 2000 03:46:19 -0500 (CDT) Date: Thu, 18 May 2000 01:46:19 -0700 From: Paul Saab To: Rasmus Skaarup Cc: freebsd-arch@freebsd.org Subject: Re: Itanium Message-ID: <20000518014619.A58363@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from rasmus@gal.dk on Thu, May 18, 2000 at 09:58:10AM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Rasmus Skaarup (rasmus@gal.dk) wrote: > > RedHat has released a alpha distribution for the 64-bit Itanium > processor. > > http://www.zdnet.com/zdnn/stories/news/0,4586,2571379,00.html?chkpt=zdhpnews01 > > And SGI is on the wagon aswell. > > http://www.sgi.com/newsroom/press_releases/2000/may/linux-ia64.html > > What is the plans for FreeBSD, will there be an Itanium distro? If so, is > there any time schedule? Work is underway. The people involved are only a month into it, and I dont think it will be done any time soon. The hope is to have support for it when Intel launches. -- Paul Saab Technical Yahoo paul@mu.org - ps@yahoo-inc.com - ps@freebsd.org Do You .. uhh .. Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 18 8:46:24 2000 Delivered-To: freebsd-arch@freebsd.org Received: from obie.softweyr.com (obie.softweyr.com [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id BE74937B5F5 for ; Thu, 18 May 2000 08:46:21 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (homer.softweyr.com [204.68.178.39]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id JAA16109; Thu, 18 May 2000 09:46:03 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <392410CB.6B86AA@softweyr.com> Date: Thu, 18 May 2000 09:48:27 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Doug Rabson Cc: arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug Rabson wrote: > > The BSD/OS mutex code includes a compile-time-selected debugging feature > which automatically detects locking hierarchy violations. Anyway, using a > mutex here doesn't add to locking complexity since the mutex would be > exited before calling the task's callback and re-entered after. Wouldn't it make more sense to provide an inversion-proof semaphore? Or is that what they're doing? -- "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 Thu May 18 8:57:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id 2C07737B50D for ; Thu, 18 May 2000 08:57:44 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id JAA05148; Thu, 18 May 2000 09:57:19 -0600 (MDT) Message-Id: <200005181557.JAA05148@berserker.bsdi.com> To: Wes Peters Cc: Doug Rabson , arch@freebsd.org Subject: Re: A new api for asynchronous task execution From: Chuck Paterson Date: Thu, 18 May 2000 09:57:19 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG } }Wouldn't it make more sense to provide an inversion-proof semaphore? }Or is that what they're doing? Not quite sure what you mean. The lock checking done now is to detect without actually having to have the deadlock occur the following thread 1 acquires lock "a" and then tries to acquire lock "b" thread 2 acquires lock "b" and then tries to acquire lock "a" There isn't really any automagic fix for this. If you are talking about running processes in order based on scheduling priority, this is propagated though mutexs which have been blocked on. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 18 10:17:37 2000 Delivered-To: freebsd-arch@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 02FDC37B50F; Thu, 18 May 2000 10:17:25 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Thu, 18 May 2000 13:17:22 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Chuck Paterson Cc: Mike Smith , Bruce Evans , "Jeroen C. van Gelderen" , Doug Rabson , arch@freebsd.org Subject: Re: A new api for asynchronous task execution (2) In-Reply-To: <200005170406.WAA22297@berserker.bsdi.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, 16 May 2000, Chuck Paterson wrote: > This really is a very valid statement/complaint. The "M_" > prefix used with the mutex stuff in BSD/OS is in common with the > mbuf stuff. We, or maybe just I, though about this quite a bit > before deciding to go with the M_ for mutexs. I don't know that > anybody else really cared. Even though there were valid reasons > for trying to keep the names short, I'm not at all sure that the > right decision was reached. All of the macros start with mtx_ > (mtx_enter, mtx_exit, mtx_try_enter). It may be that a global pass > should be made and all the mtx "M_" should be changed to "MTX_". > Comments? Quick, identify the structes that the following belong to: M_WAIT, M_DEF, M_NOWAIT, M_DONTWAIT, M_EXT, M_WAITOK It's an exercise in frustration keeping these things separate in your mind when you're using them all. No prefixes are absolute evil, but single letter prefixes are almost as evil. People aren't made to keep track of names that similar, especially when the suffixes are homonyms! Keeping things short makes keeping style(9) "easier", but it's hell on the programmer. > On a slightly related note. I see that putting prefixes on > structure elements appears less common in FreeBSD than BSD/OS. Is > this a conscience decision, or something that just happened because > the compiler doesn't require it anymore? Actually anymore is a real > long time now. Anyway, I can say with a fair amount of certainty > that when it comes time to go around locking up the kernel this > isn't going to be popular. When using tools like cscope/glimpse looking > for foo_timeout is much more productive than just looking for > timeout. There are some of these in the BSD/OS kernel and making > sure all references were covered was a real pain. There are tons of these in the FreeBSD kernel, but it doesn't seem to be as pervasive as you say it is in the BSD/OS kernel. I seem to have taken after the old hats insofar as I religiously prefix a structure's members. I use abbreviations here because there is no namespace clash, and I often use the full structure name for macros because those can easily clash. Since functions are just about as likely to clash as macros, I usually use the full structure name in a support function. Real world e.g.: struct ttree { struct ttree *tt_low, *tt_high; /* low and high branches */ union { struct ttree *ttu_equal; /* equal branch OR */ void *ttu_data; /* data (pointer) */ } tt_un; ... #define TT_VALID 0x0001 /* is it here, or removed? */ ... struct ttree *ttree_add(struct ttree *head, char *s, void *userdata); I'd love for more people to adopt this style, not just because it's the style I use ;), but because it has a deep precedent and long-standing (proven) justifications. It seems like there's a fad recently that many people don't do it, perhaps because they don't like the "tradition" of it or just that it seems redundant to them. I learned my coding style entirely from the FreeBSD kernel and some of the userland code, and have picked up the good habit from there. I'm not saying this to disrespect anyone in anyway, just to express that it really can be quite natural to have and think in this style. > Chuck -- 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 Thu May 18 13: 3:32 2000 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by hub.freebsd.org (Postfix) with ESMTP id 8729137B7C5 for ; Thu, 18 May 2000 13:03:26 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 12sWVv-0008lG-0W; Thu, 18 May 2000 21:03:23 +0100 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 VAA45927; Thu, 18 May 2000 21:08:38 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Thu, 18 May 2000 21:07:43 +0100 (BST) From: Doug Rabson To: Wes Peters Cc: arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution In-Reply-To: <392410CB.6B86AA@softweyr.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 Thu, 18 May 2000, Wes Peters wrote: > Doug Rabson wrote: > > > > The BSD/OS mutex code includes a compile-time-selected debugging feature > > which automatically detects locking hierarchy violations. Anyway, using a > > mutex here doesn't add to locking complexity since the mutex would be > > exited before calling the task's callback and re-entered after. > > Wouldn't it make more sense to provide an inversion-proof semaphore? > Or is that what they're doing? I'm sure Chuck can describe it better than me. As I understand it, the BSD/OS object is a simple counting mutex which comes in both blocking and spinning forms. There is a set of strict rules for mutex nesting which the debugging code uses to detect e.g. deadly embrace etc. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 18 13:20:23 2000 Delivered-To: freebsd-arch@freebsd.org Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by hub.freebsd.org (Postfix) with ESMTP id 084DC37B51E for ; Thu, 18 May 2000 13:20:07 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 12sWly-0002Et-0A for arch@freebsd.org; Thu, 18 May 2000 20:19:59 +0000 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 VAA46035 for ; Thu, 18 May 2000 21:25:08 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Thu, 18 May 2000 21:24:13 +0100 (BST) From: Doug Rabson To: arch@freebsd.org Subject: A new api for asynchronous task execution (3) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1970571438-958681453=:73457" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1970571438-958681453=:73457 Content-Type: TEXT/PLAIN; charset=US-ASCII Ok, I think this version is starting to look worth committing. This one adds priority sorted queueing, uses structure field prefixes and provides convenience macros for declaring queues. TASKQUEUE(9) FreeBSD Kernel Developer's Manual TASKQUEUE(9) NAME taskqueue - asynchronous task execution SYNOPSIS #include #include #include typedef void (*task_fn)(void *context, int pending); typedef void (*taskqueue_enqueue_fn)(void *context); struct task { STAILQ_ENTRY(task) ta_link; /* link for queue */ int ta_pending; /* count times queued */ int ta_priority; /* priority of task in queue */ task_fn ta_func; /* task handler */ void *ta_context; /* argument for handler */ }; struct taskqueue * taskqueue_create(const char *name, int mflags, taskqueue_enqueue_fn enqueue, void *context) void taskqueue_free(struct taskqueue *queue) struct taskqueue * taskqueue_find(const char *name) void taskqueue_enqueue(struct taskqueue *queue, struct task *task) void taskqueue_run(struct taskqueue *queue) TASK_INIT(task, priority, func, context) TASKQUEUE_DECLARE(name) TASKQUEUE_DEFINE(name, enqueue, context, init) DESCRIPTION These functions provide a simple interface for asynchronous execution of code. The function taskqueue_create() is used to create new queues. The argu- ments to taskqueue_create() include a name which should be unique, a set of malloc(9) flags which specify whether the call to malloc() is allowed to sleep and a function which is called from taskqueue_enqueue() when a task is added to the queue to allow the queue to arrange to be run later (for instance by scheduling a software interrupt or waking a kernel thread). The function taskqueue_free() should be used to remove the queue from the global list of queues and free the memory used by the queue. Any tasks which are on the queue will be executed at this time. The system maintains a list of all queues which can be searched using taskqueue_find(). The first queue whose name matches is returned, other- wise NULL. To add a task to the list of tasks queued on a taskqueue, call taskqueue_enqueue() with pointers to the queue and task. If the task's ta_pending field is non-zero, then it is simply incremented to reflect the number of times the task was enqueued. Otherwise, the task is added to the list before the first task which has a lower ta_priority value or at the end of the list if no tasks have a lower priority. Enqueueing a task does not perform any memory allocation which makes it suitable for calling from an interrupt handler. To execute all the tasks on a queue, call taskqueue_run(). When a task is executed, first it is removed from the queue, the value of ta_pending is recorded and the field is zeroed. The function ta_func from the task structure is called with the value of the field ta_context its first ar- gument and the value of ta_pending as its second argument. A convenience macro, TASK_INIT(task, priority, func, context) is provided to initialise a task structure. The values of priority, func, and context are simply copied into the task structure fields and the ta_pending field is cleared. Two macros TASKQUEUE_DECLARE(name) and TASKQUEUE_DEFINE(name, enqueue, context, init) are used to declare a reference to a global queue and to define the implementation of the queue. The TASKQUEUE_DEFINE() macro ar- ranges to call taskqueue_create() with the values of its name, enqueue and context arguments during system initialisation. After calling taskqueue_create(), the init argument to the macro is executed as a C statement, allowing any further initialisation to be performed (such as registering an interrupt handler etc.) The system provides a global taskqueue, taskqueue_swi, which is run via a software interrupt mechanism. To use this queue, call taskqueue_enqueue() with the value of the global variable taskqueue_swi. The queue will be run at splsofttq(). This queue can be used, for instance, for implementing interrupt handlers which must perform a significant amount of processing in the handler. The hardware interrupt handler would perform minimal processing of the interrupt and then enqueue a task to finish the work. This reduces the amount of time spent with interrupts disabled to a minimum. HISTORY This interface first appeared in FreeBSD 5.0. There is a similar facili- ty called tqueue in the Linux kernel. AUTHORS This man page was written by Doug Rabson. FreeBSD May 12, 2000 2 -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 --0-1970571438-958681453=:73457 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="taskqueue.9" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="taskqueue.9" LlwiIC0qLSBucm9mZiAtKi0NCi5cIg0KLlwiIENvcHlyaWdodCAoYykgMjAw MCBEb3VnIFJhYnNvbg0KLlwiDQouXCIgQWxsIHJpZ2h0cyByZXNlcnZlZC4N Ci5cIg0KLlwiIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlLg0KLlwi DQouXCIgUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJp bmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0DQouXCIgbW9kaWZpY2F0aW9u LCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBj b25kaXRpb25zDQouXCIgYXJlIG1ldDoNCi5cIiAxLiBSZWRpc3RyaWJ1dGlv bnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHly aWdodA0KLlwiICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMg YW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4NCi5cIiAyLiBSZWRpc3Ry aWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFi b3ZlIGNvcHlyaWdodA0KLlwiICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNv bmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUN Ci5cIiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMg cHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLg0KLlwiDQouXCIgVEhJ UyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgREVWRUxPUEVSUyBgYEFT IElTJycgQU5EIEFOWSBFWFBSRVNTIE9SDQouXCIgSU1QTElFRCBXQVJSQU5U SUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFIElNUExJ RUQgV0FSUkFOVElFUw0KLlwiIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklU TkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UgQVJFIERJU0NMQUlNRUQu DQouXCIgSU4gTk8gRVZFTlQgU0hBTEwgVEhFIERFVkVMT1BFUlMgQkUgTElB QkxFIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwNCi5cIiBJTkNJREVOVEFM LCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwgREFNQUdF UyAoSU5DTFVESU5HLCBCVVQNCi5cIiBOT1QgTElNSVRFRCBUTywgUFJPQ1VS RU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUyBPUiBTRVJWSUNFUzsgTE9TUyBP RiBVU0UsDQouXCIgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5U RVJSVVBUSU9OKSBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZDQouXCIgVEhF T1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNU IExJQUJJTElUWSwgT1IgVE9SVA0KLlwiIChJTkNMVURJTkcgTkVHTElHRU5D RSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWSBPVVQgT0YgVEhF IFVTRSBPRg0KLlwiIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBP RiBUSEUgUE9TU0lCSUxJVFkgT0YgU1VDSCBEQU1BR0UuDQouXCINCi5cIiAk RnJlZUJTRCQNCi5cIg0KLkRkIE1heSAxMiwgMjAwMA0KLkR0IFRBU0tRVUVV RSA5DQouT3MgRnJlZUJTRA0KLlNoIE5BTUUNCi5ObSB0YXNrcXVldWUNCi5O ZCBhc3luY2hyb25vdXMgdGFzayBleGVjdXRpb24NCi5TaCBTWU5PUFNJUw0K LkZkICNpbmNsdWRlIDxzeXMvcGFyYW0uaD4NCi5GZCAjaW5jbHVkZSA8c3lz L3F1ZXVlLmg+DQouRmQgI2luY2x1ZGUgPHN5cy90YXNrcXVldWUuaD4NCi5C ZCAtbGl0ZXJhbA0KDQp0eXBlZGVmIHZvaWQgKCp0YXNrX2ZuKSh2b2lkICpj b250ZXh0LCBpbnQgcGVuZGluZyk7DQoNCnR5cGVkZWYgdm9pZCAoKnRhc2tx dWV1ZV9lbnF1ZXVlX2ZuKSh2b2lkICpjb250ZXh0KTsNCg0Kc3RydWN0IHRh c2sgew0KCVNUQUlMUV9FTlRSWSh0YXNrKQl0YV9saW5rOwkvKiBsaW5rIGZv ciBxdWV1ZSAqLw0KCWludAkJCXRhX3BlbmRpbmc7CS8qIGNvdW50IHRpbWVz IHF1ZXVlZCAqLw0KCWludAkJCXRhX3ByaW9yaXR5OwkvKiBwcmlvcml0eSBv ZiB0YXNrIGluIHF1ZXVlICovDQoJdGFza19mbgkJCXRhX2Z1bmM7CS8qIHRh c2sgaGFuZGxlciAqLw0KCXZvaWQJCQkqdGFfY29udGV4dDsJLyogYXJndW1l bnQgZm9yIGhhbmRsZXIgKi8NCn07DQoNCi5FZA0KLkZ0IHN0cnVjdCB0YXNr cXVldWUgKg0KLkZuIHRhc2txdWV1ZV9jcmVhdGUgImNvbnN0IGNoYXIgKm5h bWUiICJpbnQgbWZsYWdzIiAidGFza3F1ZXVlX2VucXVldWVfZm4gZW5xdWV1 ZSIgInZvaWQgKmNvbnRleHQiDQouRnQgdm9pZA0KLkZuIHRhc2txdWV1ZV9m cmVlICJzdHJ1Y3QgdGFza3F1ZXVlICpxdWV1ZSINCi5GdCBzdHJ1Y3QgdGFz a3F1ZXVlICoNCi5GbiB0YXNrcXVldWVfZmluZCAiY29uc3QgY2hhciAqbmFt ZSINCi5GdCB2b2lkDQouRm4gdGFza3F1ZXVlX2VucXVldWUgInN0cnVjdCB0 YXNrcXVldWUgKnF1ZXVlIiAic3RydWN0IHRhc2sgKnRhc2siDQouRnQgdm9p ZA0KLkZuIHRhc2txdWV1ZV9ydW4gInN0cnVjdCB0YXNrcXVldWUgKnF1ZXVl Ig0KLkZuIFRBU0tfSU5JVCAidGFzayIgInByaW9yaXR5IiAiZnVuYyIgImNv bnRleHQiDQouRm4gVEFTS1FVRVVFX0RFQ0xBUkUgIm5hbWUiDQouRm4gVEFT S1FVRVVFX0RFRklORSAibmFtZSIgImVucXVldWUiICJjb250ZXh0IiAiaW5p dCINCi5TaCBERVNDUklQVElPTg0KLlBwDQpUaGVzZSBmdW5jdGlvbnMgcHJv dmlkZSBhIHNpbXBsZSBpbnRlcmZhY2UgZm9yIGFzeW5jaHJvbm91cyBleGVj dXRpb24NCm9mIGNvZGUuDQouUHANClRoZSBmdW5jdGlvbg0KLkZuIHRhc2tx dWV1ZV9jcmVhdGUNCmlzIHVzZWQgdG8gY3JlYXRlIG5ldyBxdWV1ZXMuDQpU aGUgYXJndW1lbnRzIHRvDQouRm4gdGFza3F1ZXVlX2NyZWF0ZQ0KaW5jbHVk ZSBhIG5hbWUgd2hpY2ggc2hvdWxkIGJlIHVuaXF1ZSwNCmEgc2V0IG9mDQou WHIgbWFsbG9jIDkNCmZsYWdzIHdoaWNoIHNwZWNpZnkgd2hldGhlciB0aGUg Y2FsbCB0bw0KLkZuIG1hbGxvYw0KaXMgYWxsb3dlZCB0byBzbGVlcA0KYW5k IGEgZnVuY3Rpb24gd2hpY2ggaXMgY2FsbGVkIGZyb20NCi5GbiB0YXNrcXVl dWVfZW5xdWV1ZQ0Kd2hlbiBhIHRhc2sgaXMgYWRkZWQgdG8gdGhlIHF1ZXVl DQp0byBhbGxvdyB0aGUgcXVldWUgdG8gYXJyYW5nZSB0byBiZSBydW4gbGF0 ZXINCihmb3IgaW5zdGFuY2UgYnkgc2NoZWR1bGluZyBhIHNvZnR3YXJlIGlu dGVycnVwdCBvciB3YWtpbmcgYSBrZXJuZWwNCnRocmVhZCkuDQouUHANClRo ZSBmdW5jdGlvbg0KLkZuIHRhc2txdWV1ZV9mcmVlDQpzaG91bGQgYmUgdXNl ZCB0byByZW1vdmUgdGhlIHF1ZXVlIGZyb20gdGhlIGdsb2JhbCBsaXN0IG9m IHF1ZXVlcw0KYW5kIGZyZWUgdGhlIG1lbW9yeSB1c2VkIGJ5IHRoZSBxdWV1 ZS4NCkFueSB0YXNrcyB3aGljaCBhcmUgb24gdGhlIHF1ZXVlIHdpbGwgYmUg ZXhlY3V0ZWQgYXQgdGhpcyB0aW1lLg0KLlBwDQpUaGUgc3lzdGVtIG1haW50 YWlucyBhIGxpc3Qgb2YgYWxsIHF1ZXVlcyB3aGljaCBjYW4gYmUgc2VhcmNo ZWQgdXNpbmcNCi5GbiB0YXNrcXVldWVfZmluZCAuDQpUaGUgZmlyc3QgcXVl dWUgd2hvc2UgbmFtZSBtYXRjaGVzIGlzIHJldHVybmVkLCBvdGhlcndpc2UN Ci5WYSBOVUxMIC4NCi5QcA0KVG8gYWRkIGEgdGFzayB0byB0aGUgbGlzdCBv ZiB0YXNrcyBxdWV1ZWQgb24gYSB0YXNrcXVldWUsIGNhbGwNCi5GbiB0YXNr cXVldWVfZW5xdWV1ZQ0Kd2l0aCBwb2ludGVycyB0byB0aGUgcXVldWUgYW5k IHRhc2suDQpJZiB0aGUgdGFzaydzDQouVmEgdGFfcGVuZGluZw0KZmllbGQg aXMgbm9uLXplcm8sDQp0aGVuIGl0IGlzIHNpbXBseSBpbmNyZW1lbnRlZCB0 byByZWZsZWN0IHRoZSBudW1iZXIgb2YgdGltZXMgdGhlIHRhc2sNCndhcyBl bnF1ZXVlZC4NCk90aGVyd2lzZSwNCnRoZSB0YXNrIGlzIGFkZGVkIHRvIHRo ZSBsaXN0IGJlZm9yZSB0aGUgZmlyc3QgdGFzayB3aGljaCBoYXMgYSBsb3dl cg0KLlZhIHRhX3ByaW9yaXR5DQp2YWx1ZSBvciBhdCB0aGUgZW5kIG9mIHRo ZSBsaXN0IGlmIG5vIHRhc2tzIGhhdmUgYSBsb3dlciBwcmlvcml0eS4NCkVu cXVldWVpbmcgYSB0YXNrIGRvZXMgbm90IHBlcmZvcm0gYW55IG1lbW9yeSBh bGxvY2F0aW9uIHdoaWNoIG1ha2VzDQppdCBzdWl0YWJsZSBmb3IgY2FsbGlu ZyBmcm9tIGFuIGludGVycnVwdCBoYW5kbGVyLg0KLlBwDQpUbyBleGVjdXRl IGFsbCB0aGUgdGFza3Mgb24gYSBxdWV1ZSwNCmNhbGwNCi5GbiB0YXNrcXVl dWVfcnVuIC4NCldoZW4gYSB0YXNrIGlzIGV4ZWN1dGVkLA0KZmlyc3QgaXQg aXMgcmVtb3ZlZCBmcm9tIHRoZSBxdWV1ZSwNCnRoZSB2YWx1ZSBvZg0KLlZh IHRhX3BlbmRpbmcNCmlzIHJlY29yZGVkIGFuZCB0aGUgZmllbGQgaXMgemVy b2VkLg0KVGhlIGZ1bmN0aW9uDQouVmEgdGFfZnVuYw0KZnJvbSB0aGUgdGFz ayBzdHJ1Y3R1cmUgaXMgY2FsbGVkIHdpdGggdGhlIHZhbHVlIG9mIHRoZSBm aWVsZA0KLlZhIHRhX2NvbnRleHQNCml0cyBmaXJzdCBhcmd1bWVudA0KYW5k IHRoZSB2YWx1ZSBvZg0KLlZhIHRhX3BlbmRpbmcNCmFzIGl0cyBzZWNvbmQg YXJndW1lbnQuDQouUHANCkEgY29udmVuaWVuY2UgbWFjcm8sDQouRm4gVEFT S19JTklUICJ0YXNrIiAicHJpb3JpdHkiICJmdW5jIiAiY29udGV4dCINCmlz IHByb3ZpZGVkIHRvIGluaXRpYWxpc2UgYQ0KLlZhIHRhc2sNCnN0cnVjdHVy ZS4NClRoZSB2YWx1ZXMgb2YNCi5WYSBwcmlvcml0eSAsDQouVmEgZnVuYyAs DQphbmQNCi5WYSBjb250ZXh0DQphcmUgc2ltcGx5IGNvcGllZCBpbnRvIHRo ZSB0YXNrIHN0cnVjdHVyZSBmaWVsZHMgYW5kIHRoZQ0KLlZhIHRhX3BlbmRp bmcNCmZpZWxkIGlzIGNsZWFyZWQuDQouUHANClR3byBtYWNyb3MNCi5GbiBU QVNLUVVFVUVfREVDTEFSRSAibmFtZSINCmFuZA0KLkZuIFRBU0tRVUVVRV9E RUZJTkUgIm5hbWUiICJlbnF1ZXVlIiAiY29udGV4dCIgImluaXQiDQphcmUg dXNlZCB0byBkZWNsYXJlIGEgcmVmZXJlbmNlIHRvIGEgZ2xvYmFsIHF1ZXVl DQphbmQgdG8gZGVmaW5lIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgcXVl dWUuDQpUaGUNCi5GbiBUQVNLUVVFVUVfREVGSU5FDQptYWNybyBhcnJhbmdl cyB0byBjYWxsDQouRm4gdGFza3F1ZXVlX2NyZWF0ZQ0Kd2l0aCB0aGUgdmFs dWVzIG9mIGl0cw0KLlZhIG5hbWUgLA0KLlZhIGVucXVldWUNCmFuZA0KLlZh IGNvbnRleHQNCmFyZ3VtZW50cyBkdXJpbmcgc3lzdGVtIGluaXRpYWxpc2F0 aW9uLg0KQWZ0ZXIgY2FsbGluZw0KLkZuIHRhc2txdWV1ZV9jcmVhdGUgLA0K dGhlDQouVmEgaW5pdA0KYXJndW1lbnQgdG8gdGhlIG1hY3JvIGlzIGV4ZWN1 dGVkIGFzIGEgQyBzdGF0ZW1lbnQsDQphbGxvd2luZyBhbnkgZnVydGhlciBp bml0aWFsaXNhdGlvbiB0byBiZSBwZXJmb3JtZWQNCihzdWNoIGFzIHJlZ2lz dGVyaW5nIGFuIGludGVycnVwdCBoYW5kbGVyIGV0Yy4pDQouUHANClRoZSBz eXN0ZW0gcHJvdmlkZXMgYSBnbG9iYWwgdGFza3F1ZXVlLA0KLlZhIHRhc2tx dWV1ZV9zd2kgLA0Kd2hpY2ggaXMgcnVuIHZpYSBhIHNvZnR3YXJlIGludGVy cnVwdCBtZWNoYW5pc20uDQpUbyB1c2UgdGhpcyBxdWV1ZSwNCmNhbGwNCi5G biB0YXNrcXVldWVfZW5xdWV1ZQ0Kd2l0aCB0aGUgdmFsdWUgb2YgdGhlIGds b2JhbCB2YXJpYWJsZQ0KLlZhIHRhc2txdWV1ZV9zd2kgLg0KVGhlIHF1ZXVl IHdpbGwgYmUgcnVuIGF0DQouRm4gc3Bsc29mdHRxIC4NCi5QcA0KVGhpcyBx dWV1ZSBjYW4gYmUgdXNlZCwNCmZvciBpbnN0YW5jZSwgZm9yIGltcGxlbWVu dGluZyBpbnRlcnJ1cHQgaGFuZGxlcnMgd2hpY2ggbXVzdCBwZXJmb3JtIGEN CnNpZ25pZmljYW50IGFtb3VudCBvZiBwcm9jZXNzaW5nIGluIHRoZSBoYW5k bGVyLg0KVGhlIGhhcmR3YXJlIGludGVycnVwdCBoYW5kbGVyIHdvdWxkIHBl cmZvcm0gbWluaW1hbCBwcm9jZXNzaW5nIG9mIHRoZQ0KaW50ZXJydXB0IGFu ZCB0aGVuIGVucXVldWUgYSB0YXNrIHRvIGZpbmlzaCB0aGUgd29yay4NClRo aXMgcmVkdWNlcyB0aGUgYW1vdW50IG9mIHRpbWUgc3BlbnQgd2l0aCBpbnRl cnJ1cHRzIGRpc2FibGVkDQp0byBhIG1pbmltdW0uDQouU2ggSElTVE9SWQ0K VGhpcyBpbnRlcmZhY2UgZmlyc3QgYXBwZWFyZWQgaW4NCi5GeCA1LjAgLg0K VGhlcmUgaXMgYSBzaW1pbGFyIGZhY2lsaXR5IGNhbGxlZCB0cXVldWUgaW4g dGhlIExpbnV4IGtlcm5lbC4NCi5TaCBBVVRIT1JTDQpUaGlzIG1hbiBwYWdl IHdhcyB3cml0dGVuIGJ5DQouQW4gRG91ZyBSYWJzb24gLg0K --0-1970571438-958681453=:73457 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="taskqueue.h" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="taskqueue.h" LyotDQogKiBDb3B5cmlnaHQgKGMpIDIwMDAgRG91ZyBSYWJzb24NCiAqIEFs bCByaWdodHMgcmVzZXJ2ZWQuDQogKg0KICogUmVkaXN0cmlidXRpb24gYW5k IHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRo b3V0DQogKiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQg dGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMNCiAqIGFyZSBtZXQ6DQog KiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRh aW4gdGhlIGFib3ZlIGNvcHlyaWdodA0KICogICAgbm90aWNlLCB0aGlzIGxp c3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVy Lg0KICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3Qg cmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQNCiAqICAgIG5vdGljZSwg dGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlz Y2xhaW1lciBpbiB0aGUNCiAqICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90 aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24u DQogKg0KICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQVVU SE9SIEFORCBDT05UUklCVVRPUlMgYGBBUyBJUycnIEFORA0KICogQU5ZIEVY UFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBO T1QgTElNSVRFRCBUTywgVEhFDQogKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0Yg TUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIg UFVSUE9TRQ0KICogQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFM TCBUSEUgQVVUSE9SIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUNCiAqIEZP UiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwg RVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMDQogKiBEQU1BR0VTIChJTkNM VURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VC U1RJVFVURSBHT09EUw0KICogT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBE QVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pDQog KiBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJ VFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVA0KICogTElBQklMSVRZ LCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0Up IEFSSVNJTkcgSU4gQU5ZIFdBWQ0KICogT1VUIE9GIFRIRSBVU0UgT0YgVEhJ UyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElU WSBPRg0KICogU1VDSCBEQU1BR0UuDQogKg0KICoJJEZyZWVCU0QkDQogKi8N Cg0KI2lmbmRlZiBfU1lTX1RBU0tRVUVVRV9IXw0KI2RlZmluZSBfU1lTX1RB U0tRVUVVRV9IXw0KDQojaWZkZWYgX0tFUk5FTA0KDQpzdHJ1Y3QgdGFza3F1 ZXVlOw0KDQovKg0KICogRWFjaCB0YXNrIGluY2x1ZGVzIGEgZnVuY3Rpb24g d2hpY2ggaXMgY2FsbGVkIGZyb20NCiAqIHRhc2txdWV1ZV9ydW4oKS4gVGhl IGZpcnN0IGFyZ3VtZW50IGlzIHRha2VuIGZyb20gdGhlICd0YV9jb250ZXh0 Jw0KICogZmllbGQgb2Ygc3RydWN0IHRhc2sgYW5kIHRoZSBzZWNvbmQgYXJn dW1lbnQgaXMgYSBjb3VudCBvZiBob3cgbWFueQ0KICogdGltZXMgdGhlIHRh c2sgd2FzIGVucXVldWVkIGJlZm9yZSB0aGUgY2FsbCB0byB0YXNrcXVldWVf cnVuKCkuDQogKi8NCnR5cGVkZWYgdm9pZCAoKnRhc2tfZm4pKHZvaWQgKmNv bnRleHQsIGludCBwZW5kaW5nKTsNCg0KLyoNCiAqIEEgbm90aWZpY2F0aW9u IGNhbGxiYWNrIGZ1bmN0aW9uIHdoaWNoIGlzIGNhbGxlZCBmcm9tDQogKiB0 YXNrcXVldWVfZW5xdWV1ZSgpLiBUaGUgY29udGV4dCBhcmd1bWVudCBpcyBn aXZlbiBpbiB0aGUgY2FsbCB0bw0KICogdGFza3F1ZXVlX2NyZWF0ZSgpLiBU aGlzIGZ1bmN0aW9uIHdvdWxkIG5vcm1hbGx5IGJlIHVzZWQgdG8gYWxsb3cg dGhlDQogKiBxdWV1ZSB0byBhcnJhbmdlIHRvIHJ1biBpdHNlbGYgbGF0ZXIg KGUuZy4gYnkgc2NoZWR1bGluZyBhIHNvZnR3YXJlDQogKiBpbnRlcnJ1cHQg b3Igd2FraW5nIGEga2VybmVsIHRocmVhZCkuDQogKi8NCnR5cGVkZWYgdm9p ZCAoKnRhc2txdWV1ZV9lbnF1ZXVlX2ZuKSh2b2lkICpjb250ZXh0KTsNCg0K c3RydWN0IHRhc2sgew0KCVNUQUlMUV9FTlRSWSh0YXNrKQl0YV9saW5rOwkv KiBsaW5rIGZvciBxdWV1ZSAqLw0KCWludAkJCXRhX3BlbmRpbmc7CS8qIGNv dW50IHRpbWVzIHF1ZXVlZCAqLw0KCWludAkJCXRhX3ByaW9yaXR5OwkvKiBw cmlvcml0eSBvZiB0YXNrIGluIHF1ZXVlICovDQoJdGFza19mbgkJCXRhX2Z1 bmM7CS8qIHRhc2sgaGFuZGxlciAqLw0KCXZvaWQJCQkqdGFfY29udGV4dDsJ LyogYXJndW1lbnQgZm9yIGhhbmRsZXIgKi8NCn07DQoNCiNpZiAwCQkJCS8q IGxhdGVyICovDQovKg0KICogRmxhZ3MgZm9yIHRhc2txdWV1ZV9jcmVhdGUo KSB3aGljaCB3aWxsIGNvbnRyb2wgdGhlIHByb3BlcnRpZXMgb2YgYQ0KICog bXV0ZXggd2lsbCBiZSB1c2VkIHRvIHByb3RlY3QgdGhlIHF1ZXVlLg0KICoN CiAqIE5vdGU6IHRoaXMgaXMgbm90IGN1cnJlbnRseSB1c2VkIGJ1dCB3aWxs IGJlIHVzZWQgaW4gYSBmdXR1cmUNCiAqIGltcGxlbWVudGF0aW9uIG9mIFNN UC4NCiAqLw0KI2RlZmluZSBUUV9ERUYJCTAJLyogdXNlIGJsb2NraW5nIG11 dGV4ICovDQojZGVmaW5lIFRRX1NQSU4JCTEJLyogdXNlIHNwaW4gbXV0ZXgg Ki8NCiNlbmRpZg0KDQpzdHJ1Y3QgdGFza3F1ZXVlCSp0YXNrcXVldWVfY3Jl YXRlKGNvbnN0IGNoYXIgKm5hbWUsIGludCBtZmxhZ3MsDQoJCQkJCSAgdGFz a3F1ZXVlX2VucXVldWVfZm4gZW5xdWV1ZSwNCgkJCQkJICB2b2lkICpjb250 ZXh0KTsNCnZvaWQJCQl0YXNrcXVldWVfZnJlZShzdHJ1Y3QgdGFza3F1ZXVl ICpxdWV1ZSk7DQpzdHJ1Y3QgdGFza3F1ZXVlCSp0YXNrcXVldWVfZmluZChj b25zdCBjaGFyICpuYW1lKTsNCnZvaWQJCQl0YXNrcXVldWVfZW5xdWV1ZShz dHJ1Y3QgdGFza3F1ZXVlICpxdWV1ZSwNCgkJCQkJICBzdHJ1Y3QgdGFzayAq dGFzayk7DQp2b2lkCQkJdGFza3F1ZXVlX3J1bihzdHJ1Y3QgdGFza3F1ZXVl ICpxdWV1ZSk7DQoNCi8qDQogKiBJbml0aWFsaXNlIGEgdGFzayBzdHJ1Y3R1 cmUuDQogKi8NCiNkZWZpbmUgVEFTS19JTklUKHRhc2ssIHByaW9yaXR5LCBm dW5jLCBjb250ZXh0KSBkbyB7CVwNCiAgICB0YXNrLT50YV9wZW5kaW5nID0g MDsJCQkJXA0KICAgIHRhc2stPnRhX3ByaW9yaXR5ID0gcHJpb3JpdHk7CQkJ XA0KICAgIHRhc2stPnRhX2Z1bmMgPSBmdW5jOwkJCQlcDQogICAgdGFzay0+ dGFfY29udGV4dCA9IGNvbnRleHQ7CQkJCVwNCn0gd2hpbGUgKDApDQoNCi8q DQogKiBEZWNsYXJlIGEgcmVmZXJlbmNlIHRvIGEgdGFza3F1ZXVlLg0KICov DQojZGVmaW5lIFRBU0tRVUVVRV9ERUNMQVJFKG5hbWUpCQkJXA0KCQkJCQkJ XA0KZXh0ZXJuIHN0cnVjdCB0YXNrcXVldWUgKnRhc2txdWV1ZV8jI25hbWUN Cg0KLyoNCiAqIERlZmluZSBhbmQgaW5pdGlhbGlzZSBhIHRhc2txdWV1ZS4N CiAqLw0KI2RlZmluZSBUQVNLUVVFVUVfREVGSU5FKG5hbWUsIGVucXVldWUs IGNvbnRleHQsIGluaXQpCQlcDQoJCQkJCQkJCQlcDQpzdHJ1Y3QgdGFza3F1 ZXVlICp0YXNrcXVldWVfIyNuYW1lOwkJCQkJXA0KCQkJCQkJCQkJXA0Kc3Rh dGljIHZvaWQJCQkJCQkJCVwNCnRhc2txdWV1ZV9kZWZpbmVfIyNuYW1lKHZv aWQgKmFyZykJCQkJCVwNCnsJCQkJCQkJCQlcDQoJdGFza3F1ZXVlXyMjbmFt ZSA9CQkJCQkJXA0KCQl0YXNrcXVldWVfY3JlYXRlKCNuYW1lLCBNX05PV0FJ VCwgZW5xdWV1ZSwgY29udGV4dCk7CVwNCglpbml0OwkJCQkJCQkJXA0KfQkJ CQkJCQkJCVwNCgkJCQkJCQkJCVwNClNZU0lOSVQodGFza3F1ZXVlXyMjbmFt ZSwgU0lfU1VCX0NPTkZJR1VSRSwgU0lfT1JERVJfU0VDT05ELAkJXA0KCXRh c2txdWV1ZV9kZWZpbmVfIyNuYW1lLCBOVUxMKTsNCg0KLyoNCiAqIFRoaXMg cXVldWUgaXMgc2VydmljZWQgYnkgYSBzb2Z0d2FyZSBpbnRlcnJ1cHQgaGFu ZGxlci4gVG8gZW5xdWV1ZQ0KICogYSB0YXNrLCBjYWxsIHRhc2txdWV1ZV9l bnF1ZXVlKCZ0YXNrcXVldWVfc3dpLCAmdGFzaykuDQogKi8NClRBU0tRVUVV RV9ERUNMQVJFKHN3aSk7DQoNCiNlbmRpZiAvKiBfS0VSTkVMICovDQoNCiNl bmRpZiAvKiAhX1NZU19UQVNLUVVFVUVfSF8gKi8NCg== --0-1970571438-958681453=:73457 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="subr_taskqueue.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="subr_taskqueue.c" LyotDQogKiBDb3B5cmlnaHQgKGMpIDIwMDAgRG91ZyBSYWJzb24NCiAqIEFs bCByaWdodHMgcmVzZXJ2ZWQuDQogKg0KICogUmVkaXN0cmlidXRpb24gYW5k IHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRo b3V0DQogKiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQg dGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMNCiAqIGFyZSBtZXQ6DQog KiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRh aW4gdGhlIGFib3ZlIGNvcHlyaWdodA0KICogICAgbm90aWNlLCB0aGlzIGxp c3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVy Lg0KICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3Qg cmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQNCiAqICAgIG5vdGljZSwg dGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlz Y2xhaW1lciBpbiB0aGUNCiAqICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90 aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24u DQogKg0KICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQVVU SE9SIEFORCBDT05UUklCVVRPUlMgYGBBUyBJUycnIEFORA0KICogQU5ZIEVY UFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBO T1QgTElNSVRFRCBUTywgVEhFDQogKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0Yg TUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIg UFVSUE9TRQ0KICogQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFM TCBUSEUgQVVUSE9SIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUNCiAqIEZP UiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwg RVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMDQogKiBEQU1BR0VTIChJTkNM VURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VC U1RJVFVURSBHT09EUw0KICogT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBE QVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pDQog KiBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJ VFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVA0KICogTElBQklMSVRZ LCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0Up IEFSSVNJTkcgSU4gQU5ZIFdBWQ0KICogT1VUIE9GIFRIRSBVU0UgT0YgVEhJ UyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElU WSBPRg0KICogU1VDSCBEQU1BR0UuDQogKg0KICoJJEZyZWVCU0QkDQogKi8N Cg0KI2luY2x1ZGUgPHN5cy9wYXJhbS5oPg0KI2luY2x1ZGUgPHN5cy9xdWV1 ZS5oPg0KI2luY2x1ZGUgPHN5cy9zeXN0bS5oPg0KI2luY2x1ZGUgPHN5cy9r ZXJuZWwuaD4NCiNpbmNsdWRlIDxzeXMvdGFza3F1ZXVlLmg+DQojaW5jbHVk ZSA8c3lzL2ludGVycnVwdC5oPg0KI2luY2x1ZGUgPHN5cy9tYWxsb2MuaD4N CiNpbmNsdWRlIDxtYWNoaW5lL2lwbC5oPg0KDQpNQUxMT0NfREVGSU5FKE1f VEFTS1FVRVVFLCAidGFza3F1ZXVlIiwgIlRhc2sgUXVldWVzIik7DQoNCnN0 YXRpYyBTVEFJTFFfSEVBRCh0YXNrcXVldWVfbGlzdCwgdGFza3F1ZXVlKSB0 YXNrcXVldWVfcXVldWVzOw0KDQpzdHJ1Y3QgdGFza3F1ZXVlIHsNCglTVEFJ TFFfRU5UUlkodGFza3F1ZXVlKQl0cV9saW5rOw0KCVNUQUlMUV9IRUFEKCwg dGFzaykJdHFfcXVldWU7DQoJY29uc3QgY2hhcgkJKnRxX25hbWU7DQoJdGFz a3F1ZXVlX2VucXVldWVfZm4JdHFfZW5xdWV1ZTsNCgl2b2lkCQkJKnRxX2Nv bnRleHQ7DQp9Ow0KDQpzdHJ1Y3QgdGFza3F1ZXVlICoNCnRhc2txdWV1ZV9j cmVhdGUoY29uc3QgY2hhciAqbmFtZSwgaW50IG1mbGFncywNCgkJIHRhc2tx dWV1ZV9lbnF1ZXVlX2ZuIGVucXVldWUsIHZvaWQgKmNvbnRleHQpDQp7DQoJ c3RydWN0IHRhc2txdWV1ZSAqcXVldWU7DQoJc3RhdGljIGludCBvbmNlID0g MTsNCg0KCXF1ZXVlID0gbWFsbG9jKHNpemVvZihzdHJ1Y3QgdGFza3F1ZXVl KSwgTV9UQVNLUVVFVUUsIG1mbGFncyk7DQoJaWYgKCFxdWV1ZSkNCgkJcmV0 dXJuIDA7DQoNCglpZiAob25jZSkgew0KCQlTVEFJTFFfSU5JVCgmdGFza3F1 ZXVlX3F1ZXVlcyk7DQoJCW9uY2UgPSAwOw0KCX0NCglTVEFJTFFfSU5TRVJU X1RBSUwoJnRhc2txdWV1ZV9xdWV1ZXMsIHF1ZXVlLCB0cV9saW5rKTsNCglT VEFJTFFfSU5JVCgmcXVldWUtPnRxX3F1ZXVlKTsNCglxdWV1ZS0+dHFfbmFt ZSA9IG5hbWU7DQoJcXVldWUtPnRxX2VucXVldWUgPSBlbnF1ZXVlOw0KCXF1 ZXVlLT50cV9jb250ZXh0ID0gY29udGV4dDsNCg0KCXJldHVybiBxdWV1ZTsN Cn0NCg0Kdm9pZA0KdGFza3F1ZXVlX2ZyZWUoc3RydWN0IHRhc2txdWV1ZSAq cXVldWUpDQp7DQoJaW50IHMgPSBzcGxoaWdoKCk7DQoJdGFza3F1ZXVlX3J1 bihxdWV1ZSk7DQoJU1RBSUxRX1JFTU9WRSgmdGFza3F1ZXVlX3F1ZXVlcywg cXVldWUsIHRhc2txdWV1ZSwgdHFfbGluayk7DQoJc3BseChzKTsNCg0KCWZy ZWUocXVldWUsIE1fVEFTS1FVRVVFKTsNCn0NCg0Kc3RydWN0IHRhc2txdWV1 ZSAqDQp0YXNrcXVldWVfZmluZChjb25zdCBjaGFyICpuYW1lKQ0Kew0KCXN0 cnVjdCB0YXNrcXVldWUgKnF1ZXVlOw0KDQoJU1RBSUxRX0ZPUkVBQ0gocXVl dWUsICZ0YXNrcXVldWVfcXVldWVzLCB0cV9saW5rKQ0KCQlpZiAoIXN0cmNt cChxdWV1ZS0+dHFfbmFtZSwgbmFtZSkpDQoJCQlyZXR1cm4gcXVldWU7DQoJ cmV0dXJuIDA7DQp9DQoNCnZvaWQNCnRhc2txdWV1ZV9lbnF1ZXVlKHN0cnVj dCB0YXNrcXVldWUgKnF1ZXVlLCBzdHJ1Y3QgdGFzayAqdGFzaykNCnsNCglz dHJ1Y3QgdGFzayAqaW5zOw0KCXN0cnVjdCB0YXNrICpwcmV2Ow0KDQoJaW50 IHMgPSBzcGxoaWdoKCk7DQoNCgkvKg0KCSAqIENvdW50IG11bHRpcGxlIGVu cXVldWVzLg0KCSAqLw0KCWlmICh0YXNrLT50YV9wZW5kaW5nKSB7DQoJCXRh c2stPnRhX3BlbmRpbmcrKzsNCgkJc3BseChzKTsNCgkJcmV0dXJuOw0KCX0N Cg0KCS8qDQoJICogT3B0aW1pc2UgdGhlIGNhc2Ugd2hlbiBhbGwgdGFza3Mg aGF2ZSB0aGUgc2FtZSBwcmlvcml0eS4NCgkgKi8NCglwcmV2ID0gU1RBSUxR X0xBU1QoJnF1ZXVlLT50cV9xdWV1ZSk7DQoJaWYgKCFwcmV2IHx8IHByZXYt PnRhX3ByaW9yaXR5ID49IHRhc2stPnRhX3ByaW9yaXR5KSB7DQoJCVNUQUlM UV9JTlNFUlRfVEFJTCgmcXVldWUtPnRxX3F1ZXVlLCB0YXNrLCB0YV9saW5r KTsNCgl9IGVsc2Ugew0KCQlwcmV2ID0gMDsNCgkJZm9yIChpbnMgPSBTVEFJ TFFfRklSU1QoJnF1ZXVlLT50cV9xdWV1ZSk7IGluczsNCgkJICAgICBwcmV2 ID0gaW5zLCBpbnMgPSBTVEFJTFFfTkVYVChpbnMsIHRhX2xpbmspKQ0KCQkJ aWYgKGlucy0+dGFfcHJpb3JpdHkgPCB0YXNrLT50YV9wcmlvcml0eSkNCgkJ CQlicmVhazsNCg0KCQlpZiAocHJldikNCgkJCVNUQUlMUV9JTlNFUlRfQUZU RVIoJnF1ZXVlLT50cV9xdWV1ZSwgcHJldiwgdGFzaywgdGFfbGluayk7DQoJ CWVsc2UNCgkJCVNUQUlMUV9JTlNFUlRfSEVBRCgmcXVldWUtPnRxX3F1ZXVl LCB0YXNrLCB0YV9saW5rKTsNCgl9DQoNCgl0YXNrLT50YV9wZW5kaW5nID0g MTsNCglpZiAocXVldWUtPnRxX2VucXVldWUpDQoJCXF1ZXVlLT50cV9lbnF1 ZXVlKHF1ZXVlLT50cV9jb250ZXh0KTsNCg0KCXNwbHgocyk7DQp9DQoNCnZv aWQNCnRhc2txdWV1ZV9ydW4oc3RydWN0IHRhc2txdWV1ZSAqcXVldWUpDQp7 DQoJaW50IHM7DQoJc3RydWN0IHRhc2sgKnRhc2s7DQoJaW50IHBlbmRpbmc7 DQoNCglzID0gc3BsaGlnaCgpOw0KCXdoaWxlIChTVEFJTFFfRklSU1QoJnF1 ZXVlLT50cV9xdWV1ZSkpIHsNCgkJLyoNCgkJICogQ2FyZWZ1bGx5IHJlbW92 ZSB0aGUgZmlyc3QgdGFzayBmcm9tIHRoZSBxdWV1ZSBhbmQNCgkJICogemVy byBpdHMgcGVuZGluZyBjb3VudC4NCgkJICovDQoJCXRhc2sgPSBTVEFJTFFf RklSU1QoJnF1ZXVlLT50cV9xdWV1ZSk7DQoJCVNUQUlMUV9SRU1PVkVfSEVB RCgmcXVldWUtPnRxX3F1ZXVlLCB0YV9saW5rKTsNCgkJcGVuZGluZyA9IHRh c2stPnRhX3BlbmRpbmc7DQoJCXRhc2stPnRhX3BlbmRpbmcgPSAwOw0KCQlz cGx4KHMpOw0KDQoJCXRhc2stPnRhX2Z1bmModGFzay0+dGFfY29udGV4dCwg cGVuZGluZyk7DQoNCgkJcyA9IHNwbGhpZ2goKTsNCgl9DQoJc3BseChzKTsN Cn0NCg0Kc3RhdGljIHZvaWQNCnRhc2txdWV1ZV9zd2lfZW5xdWV1ZSh2b2lk ICpjb250ZXh0KQ0Kew0KCXNldHNvZnR0cSgpOw0KfQ0KDQpzdGF0aWMgdm9p ZA0KdGFza3F1ZXVlX3N3aV9ydW4odm9pZCkNCnsNCgl0YXNrcXVldWVfcnVu KHRhc2txdWV1ZV9zd2kpOw0KfQ0KDQpUQVNLUVVFVUVfREVGSU5FKHN3aSwg dGFza3F1ZXVlX3N3aV9lbnF1ZXVlLCAwLA0KCQkgcmVnaXN0ZXJfc3dpKFNX SV9UUSwgdGFza3F1ZXVlX3N3aV9ydW4pKTsNCg== --0-1970571438-958681453=:73457-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 18 13:46:27 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 92F7237B84C for ; Thu, 18 May 2000 13:46:19 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id NAA18087; Thu, 18 May 2000 13:45:40 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpdAAAMUaimJ; Thu May 18 13:45:29 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id NAA21595; Thu, 18 May 2000 13:45:54 -0700 (MST) From: Terry Lambert Message-Id: <200005182045.NAA21595@usr08.primenet.com> Subject: Re: Sparc & api for asynchronous task execution (2) To: cp@bsdi.com (Chuck Paterson) Date: Thu, 18 May 2000 20:45:54 +0000 (GMT) Cc: dfr@nlsystems.com (Doug Rabson), arch@FreeBSD.ORG In-Reply-To: <200005172056.OAA25889@berserker.bsdi.com> from "Chuck Paterson" at May 17, 2000 02:56:16 PM X-Mailer: ELM [version 2.5 PL2] 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 didn't realize that every function call involved a fault on the sparc > }architecture - that sounds pretty nasty. > > Actually every function call doesn't cause a fault, every > time you overflow/underflow the current set of register windows causes a > fault. (Perhaps what you meant). This means that calling a function > from the bottom most function will cause two faults, one for going down > and one eventually as you go up. > > This makes going up and down when you don't overflow > very fast at the expense of when you add to the total depth. See also: TR-91-08-01 Register Windows and User-Space Threads on the SPARC D. Keppel August 1991 University of Washington ftp://ftp.cs.washington.edu/tr/1991/08/UW-CSE-91-08-01.PS.Z for a good discussion of SPARC register windows. 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 May 18 15: 9:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from overcee.netplex.com.au (peter1.yahoo.com [208.48.107.4]) by hub.freebsd.org (Postfix) with ESMTP id 8D08237BB23 for ; Thu, 18 May 2000 15:09:27 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id E8DB41CE1; Thu, 18 May 2000 15:09:25 -0700 (PDT) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: Doug Rabson Cc: Wes Peters , arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution In-Reply-To: Message from Doug Rabson of "Thu, 18 May 2000 21:07:43 BST." Date: Thu, 18 May 2000 15:09:25 -0700 From: Peter Wemm Message-Id: <20000518220925.E8DB41CE1@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug Rabson wrote: > On Thu, 18 May 2000, Wes Peters wrote: > > > Doug Rabson wrote: > > > > > > The BSD/OS mutex code includes a compile-time-selected debugging feature > > > which automatically detects locking hierarchy violations. Anyway, using a > > > mutex here doesn't add to locking complexity since the mutex would be > > > exited before calling the task's callback and re-entered after. > > > > Wouldn't it make more sense to provide an inversion-proof semaphore? > > Or is that what they're doing? > > I'm sure Chuck can describe it better than me. As I understand it, the > BSD/OS object is a simple counting mutex which comes in both blocking and > spinning forms. There is a set of strict rules for mutex nesting which the > debugging code uses to detect e.g. deadly embrace etc. That would be the WITNESS stuff, right? (for verifying and enforcing the rules) Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 18 15:42: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id ADA2F37BD9A for ; Thu, 18 May 2000 15:42:02 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id QAA06732; Thu, 18 May 2000 16:41:37 -0600 (MDT) Message-Id: <200005182241.QAA06732@berserker.bsdi.com> To: Peter Wemm Cc: Doug Rabson , Wes Peters , arch@freebsd.org Subject: Re: A new api for asynchronous task execution From: Chuck Paterson Date: Thu, 18 May 2000 16:41:36 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Correct. Chuck } }That would be the WITNESS stuff, right? (for verifying and enforcing the }rules) } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 18 16:40:35 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 3C08737BDF5 for ; Thu, 18 May 2000 16:40:27 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id QAA05722; Thu, 18 May 2000 16:40:33 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp05.primenet.com, id smtpdAAALRaGil; Thu May 18 16:40:27 2000 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id QAA11883; Thu, 18 May 2000 16:40:18 -0700 (MST) From: Terry Lambert Message-Id: <200005182340.QAA11883@usr06.primenet.com> Subject: Re: A new api for asynchronous task execution To: cp@bsdi.com (Chuck Paterson) Date: Thu, 18 May 2000 23:40:17 +0000 (GMT) Cc: wes@softweyr.com (Wes Peters), dfr@nlsystems.com (Doug Rabson), arch@FreeBSD.ORG In-Reply-To: <200005181557.JAA05148@berserker.bsdi.com> from "Chuck Paterson" at May 18, 2000 09:57:19 AM X-Mailer: ELM [version 2.5 PL2] 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 > }Wouldn't it make more sense to provide an inversion-proof semaphore? > }Or is that what they're doing? > > Not quite sure what you mean. The lock checking done > now is to detect without actually having to have the deadlock > occur the following > > thread 1 acquires lock "a" and then tries to acquire lock "b" > thread 2 acquires lock "b" and then tries to acquire lock "a" > > > There isn't really any automagic fix for this. Djikstra would disagree; this is the classic form for something to which he would apply his "banker's algorithm" and pre reserve both "a" and "b" for thread 1, before it ever became an issue. Deadlock avoidance is thus one way to deal with the problem. There are better soloutions that permit resource risk, however, but they require that you be able to back completely out of a partial transaction, and retry the whole thing, e.g. continuing: thread 2 gets EWOULDBLOCK thread 2 gifts lock "b" to thread 1 thread 2 sleeps _first in line_ to reacquire lock "b" thread 1 acquires lock "a" thread 1 completes thread 1 releases lock "b" thread 2 acquires lock "b" thread 2 attempts to acquire lock "a" ... > If you are talking about running processes in > order based on scheduling priority, this is propagated > though mutexs which have been blocked on. Resource priority (as shown above, when thread 2 gets to be first in line as a reward for not continuing to hold lock "b" when it was needed by thread 1) is a better model, since it avoids the "deadly embrace" deadlock. If we are talking RT priority, then there is always the resource preemption model; this also requires special coding and design practices, e.g.: A: thread 2 is higher priority thread 2 preempts lock "a" from the clutches of thread 1 thread 2 completes thread 2 does not free, but returns lock "a" to thread 1 B: thread 1 is higher priority thread 1 preempts lock "b" from the clutches of thread 2 thread 1 completes thread 1 does not free, but returns lock "b" to thread 2 There are better graphical soloutions which woild allow concurrent access; SIX locking is required to be able to implement these, and increases complexity, but the increase in concurrency is generally worth the effort. 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 May 18 17: 1: 7 2000 Delivered-To: freebsd-arch@freebsd.org 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 4AD3F37B546 for ; Thu, 18 May 2000 17:01:03 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost [127.0.0.1]) by rah.star-gate.com (8.9.3/8.9.3) with ESMTP id RAA07951; Thu, 18 May 2000 17:00:35 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <200005190000.RAA07951@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert Cc: cp@bsdi.com (Chuck Paterson), wes@softweyr.com (Wes Peters), dfr@nlsystems.com (Doug Rabson), arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution In-reply-to: Your message of "Thu, 18 May 2000 23:40:17 -0000." <200005182340.QAA11883@usr06.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 May 2000 17:00:35 -0700 From: Amancio Hasty Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > }Wouldn't it make more sense to provide an inversion-proof semaphore? > > }Or is that what they're doing? > > > > Not quite sure what you mean. The lock checking done > > now is to detect without actually having to have the deadlock > > occur the following > > > > thread 1 acquires lock "a" and then tries to acquire lock "b" > > thread 2 acquires lock "b" and then tries to acquire lock "a" > > > > > > There isn't really any automagic fix for this. > > Djikstra would disagree; this is the classic form for something > to which he would apply his "banker's algorithm" and pre reserve > both "a" and "b" for thread 1, before it ever became an issue. > > Deadlock avoidance is thus one way to deal with the problem. > > There are better soloutions that permit resource risk, however, > but they require that you be able to back completely out of a > partial transaction, and retry the whole thing, e.g. continuing: Hmm... Given that in an OS scenario one may not be able to restore the state of a partially committed transaction , I think that transaction style processing is not appropiate for exclusiveness of operations. Unless of course one is willing to virtualize the machine states and then commit a fully completed transaction which is somewhat what databases such as Oracle do. -- 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 May 18 17: 4:58 2000 Delivered-To: freebsd-arch@freebsd.org 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 B928737B546 for ; Thu, 18 May 2000 17:04:56 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost [127.0.0.1]) by rah.star-gate.com (8.9.3/8.9.3) with ESMTP id RAA08000; Thu, 18 May 2000 17:04:39 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <200005190004.RAA08000@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert Cc: cp@bsdi.com (Chuck Paterson), wes@softweyr.com (Wes Peters), dfr@nlsystems.com (Doug Rabson), arch@FreeBSD.ORG Subject: High Performance Synchronization In-reply-to: Your message of "Thu, 18 May 2000 23:40:17 -0000." <200005182340.QAA11883@usr06.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 May 2000 17:04:39 -0700 From: Amancio Hasty Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a nice web page on high performance locks and it shows how to implement them 8) http://www.cs.rochester.edu/u/scott/synchronization/ Enjoy -- 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 May 18 20: 5:39 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by hub.freebsd.org (Postfix) with ESMTP id 3DC1D37BA18; Thu, 18 May 2000 20:05:33 -0700 (PDT) (envelope-from chris@holly.calldei.com) Received: from holly.calldei.com ([208.191.155.7]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FUS0037JDWODQ@mta5.rcsntx.swbell.net>; Thu, 18 May 2000 22:05:13 -0500 (CDT) Received: (from chris@localhost) by holly.calldei.com (8.9.3/8.9.3) id WAA19041; Thu, 18 May 2000 22:06:06 -0500 (CDT envelope-from chris) Date: Thu, 18 May 2000 22:06:05 -0500 From: Chris Costello Subject: Review for basename(3) and dirname(3) implementation. To: arch@FreeBSD.org Cc: committers@FreeBSD.org Reply-To: chris@calldei.com Message-id: <20000518220605.B11065@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've implemented an XPG4.2-conforming version of basename(3) and dirname(3), along with reentrant basename_r(3) and dirname_r(3) functions. I would like some feedback for this code and hopefully it can be committed soon. The new files are available at http://people.FreeBSD.org/~chris/basename/ -- libgen.h to go in src/include and the rest to go in lib/libc/gen. -- |Chris Costello |The only way to get rid of temptation is to yield to it. `-------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 18 20:25: 6 2000 Delivered-To: freebsd-arch@freebsd.org Received: from po4.glue.umd.edu (po4.glue.umd.edu [128.8.10.124]) by hub.freebsd.org (Postfix) with ESMTP id A6A2037BA18; Thu, 18 May 2000 20:24:58 -0700 (PDT) (envelope-from howardjp@glue.umd.edu) Received: from z.glue.umd.edu (root@z.glue.umd.edu [128.8.10.71]) by po4.glue.umd.edu (8.9.3/8.9.3) with ESMTP id XAA21004; Thu, 18 May 2000 23:24:53 -0400 (EDT) Received: from z.glue.umd.edu (sendmail@localhost [127.0.0.1]) by z.glue.umd.edu (8.9.3/8.9.3) with SMTP id XAA07412; Thu, 18 May 2000 23:24:52 -0400 (EDT) Received: from localhost (howardjp@localhost) by z.glue.umd.edu (8.9.3/8.9.3) with ESMTP id XAA07408; Thu, 18 May 2000 23:24:52 -0400 (EDT) X-Authentication-Warning: z.glue.umd.edu: howardjp owned process doing -bs Date: Thu, 18 May 2000 23:24:51 -0400 (EDT) From: James Howard To: Chris Costello Cc: arch@FreeBSD.ORG, committers@FreeBSD.ORG Subject: Re: Review for basename(3) and dirname(3) implementation. In-Reply-To: <20000518220605.B11065@holly.calldei.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 Thu, 18 May 2000, Chris Costello wrote: > I've implemented an XPG4.2-conforming version of basename(3) > and dirname(3), along with reentrant basename_r(3) and > dirname_r(3) functions. > > I would like some feedback for this code and hopefully it can > be committed soon. > > The new files are available at > http://people.FreeBSD.org/~chris/basename/ -- libgen.h to go in > src/include and the rest to go in lib/libc/gen. Kill bin/12960 and bin/12962 if and when these go through. Jamie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 18 22:17:20 2000 Delivered-To: freebsd-arch@freebsd.org Received: from obie.softweyr.com (obie.softweyr.com [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id 11C3237BD10 for ; Thu, 18 May 2000 22:17:17 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (homer.softweyr.com [204.68.178.39]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id XAA17555; Thu, 18 May 2000 23:17:06 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <3924CEE4.55551D82@softweyr.com> Date: Thu, 18 May 2000 23:19:32 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Chuck Paterson Cc: Doug Rabson , arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution References: <200005181557.JAA05148@berserker.bsdi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chuck Paterson wrote: > > } > }Wouldn't it make more sense to provide an inversion-proof semaphore? > }Or is that what they're doing? > > Not quite sure what you mean. The lock checking done > now is to detect without actually having to have the deadlock > occur the following > > thread 1 acquires lock "a" and then tries to acquire lock "b" > thread 2 acquires lock "b" and then tries to acquire lock "a" > > There isn't really any automagic fix for this. Ah, I misunderstood, this is a deadly embrace. There are automagic fixes, but they get expensive REALLY fast. Still, it's a good option to turn on for debugging. > If you are talking about running processes in > order based on scheduling priority, this is propagated > though mutexs which have been blocked on. No, speaking of temporarily elevating the priority of a process holding a lock to the highest priority of all processes blocking on the lock. -- "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 Thu May 18 22:29:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.cdrom.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id 8011B37B90F for ; Thu, 18 May 2000 22:29:09 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id WAA06634; Thu, 18 May 2000 22:29:56 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200005190529.WAA06634@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Wes Peters Cc: Chuck Paterson , Doug Rabson , arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution In-reply-to: Your message of "Thu, 18 May 2000 23:19:32 MDT." <3924CEE4.55551D82@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 May 2000 22:29:56 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > If you are talking about running processes in > > order based on scheduling priority, this is propagated > > though mutexs which have been blocked on. > > No, speaking of temporarily elevating the priority of a process holding > a lock to the highest priority of all processes blocking on the lock. You could call this "priority lending" so that the rest of us understand what you're talking about. 8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 18 23: 5:12 2000 Delivered-To: freebsd-arch@freebsd.org Received: from obie.softweyr.com (obie.softweyr.com [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id B1BF937BA3C for ; Thu, 18 May 2000 23:05:09 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (homer.softweyr.com [204.68.178.39]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id AAA17630; Fri, 19 May 2000 00:04:54 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <3924DA18.392990EA@softweyr.com> Date: Fri, 19 May 2000 00:07:20 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Chuck Paterson , Doug Rabson , arch@FreeBSD.ORG Subject: Re: Sparc & api for asynchronous task execution (2) References: <200005182045.NAA21595@usr08.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 didn't realize that every function call involved a fault on the sparc > > }architecture - that sounds pretty nasty. > > > > Actually every function call doesn't cause a fault, every > > time you overflow/underflow the current set of register windows causes a > > fault. (Perhaps what you meant). This means that calling a function > > from the bottom most function will cause two faults, one for going down > > and one eventually as you go up. > > > > This makes going up and down when you don't overflow > > very fast at the expense of when you add to the total depth. The register window sizes weren't picked willy-nilly. The SPARC default size is 7 windows, chosen after months of analyzing every M68K SunOS program they could get their hands, including compiled C, Pascal, LISP, and Fortran programs. I suspect C++ and Java probably skew these stats a little. This might account for the 8 windows in more modern SPARC processors. -- "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 Thu May 18 23:36:22 2000 Delivered-To: freebsd-arch@freebsd.org Received: from obie.softweyr.com (obie.softweyr.com [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id 8149937BC9F; Thu, 18 May 2000 23:36:17 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (homer.softweyr.com [204.68.178.39]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id AAA17739; Fri, 19 May 2000 00:36:07 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <3924E16A.B1123749@softweyr.com> Date: Fri, 19 May 2000 00:38:34 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mike Smith Cc: Chuck Paterson , Doug Rabson , arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution References: <200005190529.WAA06634@mass.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith wrote: > > > > If you are talking about running processes in > > > order based on scheduling priority, this is propagated > > > though mutexs which have been blocked on. > > > > No, speaking of temporarily elevating the priority of a process holding > > a lock to the highest priority of all processes blocking on the lock. > > You could call this "priority lending" so that the rest of us understand > what you're talking about. 8) The only system I've ever worked on that implements them refer to them as inversion-safe or inversion-proof semaphores. I've never seen another name, including "priority lending", in any literature or article on the subject. -- "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 Thu May 18 23:44: 1 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (Postfix) with ESMTP id CC3EA37B771; Thu, 18 May 2000 23:43:53 -0700 (PDT) (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 XAA19619; Thu, 18 May 2000 23:43:50 -0700 (PDT) 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 IAA04985; Fri, 19 May 2000 08:43:48 +0200 (MET DST) Message-ID: <3924E25D.DEB9F987@germany.sun.com> Date: Fri, 19 May 2000 08:42:37 +0200 From: Michael Schuster - TSC SunOS Germany Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.73 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Wes Peters Cc: Mike Smith , Chuck Paterson , Doug Rabson , arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution References: <200005190529.WAA06634@mass.cdrom.com> <3924E16A.B1123749@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: > > Mike Smith wrote: > > > > > > If you are talking about running processes in > > > > order based on scheduling priority, this is propagated > > > > though mutexs which have been blocked on. > > > > > > No, speaking of temporarily elevating the priority of a process holding > > > a lock to the highest priority of all processes blocking on the lock. > > > > You could call this "priority lending" so that the rest of us understand > > what you're talking about. 8) > > The only system I've ever worked on that implements them refer to > them as inversion-safe or inversion-proof semaphores. I've never seen > another name, including "priority lending", in any literature or > article on the subject. 'scuse me for barging in - this sounds like what I know as "priority inheritance" (as one solution to the priority inversion problem). Are we talking of the same thing here? If no, what _is_ the difference? If yes, I could probably dig up one or two papers using these terms (we do at Sun, but that's not necessarily the place you're looking ... :-) cheers Michael -- Michael Schuster / Michael.Schuster@germany.sun.com Sun Microsystems GmbH / Richard-Reitzner Allee 8, D-85540 Haar (+49 89) 46008 974 / x12974 Recursion, n.: see 'Recursion' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 18 23:49:13 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.cdrom.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id 1CD1B37B771 for ; Thu, 18 May 2000 23:49:09 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id XAA06921; Thu, 18 May 2000 23:50:14 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200005190650.XAA06921@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Michael Schuster - TSC SunOS Germany Cc: arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution In-reply-to: Your message of "Fri, 19 May 2000 08:42:37 +0200." <3924E25D.DEB9F987@germany.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 May 2000 23:50:14 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 'scuse me for barging in - this sounds like what I know as "priority > inheritance" (as one solution to the priority inversion problem). Are we > talking of the same thing here? If no, what _is_ the difference? If yes, I > could probably dig up one or two papers using these terms (we do at Sun, > but that's not necessarily the place you're looking ... :-) Same thing, yes. I seem to recall there being some issues with it, too, which might make for interesting reading. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 19 1:42:22 2000 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by hub.freebsd.org (Postfix) with ESMTP id 8D91837BEC4; Fri, 19 May 2000 01:42:12 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by anchor-post-33.mail.demon.net with esmtp (Exim 2.12 #1) id 12siME-0005xe-0X; Fri, 19 May 2000 09:42:10 +0100 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 JAA47063; Fri, 19 May 2000 09:47:28 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Fri, 19 May 2000 09:46:24 +0100 (BST) From: Doug Rabson To: Wes Peters Cc: Mike Smith , Chuck Paterson , arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution In-Reply-To: <3924E16A.B1123749@softweyr.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 Fri, 19 May 2000, Wes Peters wrote: > Mike Smith wrote: > > > > > > If you are talking about running processes in > > > > order based on scheduling priority, this is propagated > > > > though mutexs which have been blocked on. > > > > > > No, speaking of temporarily elevating the priority of a process holding > > > a lock to the highest priority of all processes blocking on the lock. > > > > You could call this "priority lending" so that the rest of us understand > > what you're talking about. 8) > > The only system I've ever worked on that implements them refer to > them as inversion-safe or inversion-proof semaphores. I've never seen > another name, including "priority lending", in any literature or > article on the subject. Anyway, whatever we choose to call it, the BSD/OS mutex does have support for priority lending. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 19 2:29:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 1DD9237BA75 for ; Fri, 19 May 2000 02:29:10 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id LAA62895; Fri, 19 May 2000 11:28:58 +0200 (CEST) (envelope-from des@flood.ping.uio.no) To: Hajimu UMEMOTO (=?iso-2022-jp?b?GyRCR19LXBsoQiAbJEJIJRsoQg==?=) Cc: arch@freebsd.org Subject: Re: fetch(1) References: <200005122016.e4CKGtF38185@peace.mahoroba.org> <200005161852.e4GIqhF74521@peace.mahoroba.org> <200005162001.e4GK1bF75342@peace.mahoroba.org> From: Dag-Erling Smorgrav Date: 19 May 2000 11:28:57 +0200 In-Reply-To: Hajimu UMEMOTO's message of "Wed, 17 May 2000 05:01:37 +0900 (JST)" Message-ID: Lines: 32 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hajimu UMEMOTO ($BG_K\(B $BH%(B) writes: > One more. > Fetch to ftp.openbsd.org fails with `999 Protocol error'. > Ftp.openbsd.org seems to return '230 ' without any trailing message. > [debugging output and patch deleted] Actually, the correct fix is: Index: ftp.c =================================================================== RCS file: /home/ncvs/src/lib/libfetch/ftp.c,v retrieving revision 1.19 diff -u -r1.19 ftp.c --- ftp.c 2000/05/15 08:24:58 1.19 +++ ftp.c 2000/05/19 09:25:59 @@ -100,7 +100,8 @@ static int last_code; #define isftpreply(foo) (isdigit(foo[0]) && isdigit(foo[1]) \ - && isdigit(foo[2]) && foo[3] == ' ') + && isdigit(foo[2]) \ + && (foo[3] == ' ' || foo[3] == '\0')) #define isftpinfo(foo) (isdigit(foo[0]) && isdigit(foo[1]) \ && isdigit(foo[2]) && foo[3] == '-') There are some places in ftp.c (e.g. the passive ftp code) that assume there is text after the status code; I'll see what I can do to fix them. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 19 2:43:19 2000 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 04BE537C052 for ; Fri, 19 May 2000 02:43:10 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id LAA62937; Fri, 19 May 2000 11:43:03 +0200 (CEST) (envelope-from des@flood.ping.uio.no) To: Hajimu UMEMOTO (=?iso-2022-jp?b?GyRCR19LXBsoQiAbJEJIJRsoQg==?=) Cc: arch@FreeBSD.ORG Subject: Re: fetch(1) References: <200005122016.e4CKGtF38185@peace.mahoroba.org> <200005161852.e4GIqhF74521@peace.mahoroba.org> <200005162001.e4GK1bF75342@peace.mahoroba.org> From: Dag-Erling Smorgrav Date: 19 May 2000 11:43:03 +0200 In-Reply-To: Dag-Erling Smorgrav's message of "19 May 2000 11:28:57 +0200" Message-ID: Lines: 34 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav writes: > There are some places in ftp.c (e.g. the passive ftp code) that assume > there is text after the status code; I'll see what I can do to fix them. I think this fixes the PASV case: Index: ftp.c =================================================================== RCS file: /home/ncvs/src/lib/libfetch/ftp.c,v retrieving revision 1.19 diff -u -r1.19 ftp.c --- ftp.c 2000/05/15 08:24:58 1.19 +++ ftp.c 2000/05/19 09:41:42 @@ -238,11 +239,13 @@ * is IMHO the one and only weak point in the FTP protocol. */ ln = last_reply; - for (p = ln + 3; !isdigit(*p); p++) + for (p = ln + 3; *p && !isdigit(*p); p++) /* nothing */ ; - for (p--, i = 0; i < 6; i++) { - p++; /* skip the comma */ + for (i = 0; *p, i < 6; i++, p++) addr[i] = strtol(p, &p, 10); + if (i < 6) { + e = 999; + goto ouch; } /* seek to required offset */ DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 19 4: 6: 4 2000 Delivered-To: freebsd-arch@freebsd.org Received: from hitpro.hitachi.co.jp (hitpro.hitachi.co.jp [133.145.224.7]) by hub.freebsd.org (Postfix) with ESMTP id 47CF137BED7 for ; Fri, 19 May 2000 04:06:00 -0700 (PDT) (envelope-from ume@bisd.hitachi.co.jp) Received: from bisdgw.bisd.hitachi.co.jp by hitpro.hitachi.co.jp (8.9.3/3.7W-hitpro) id UAA12891; Fri, 19 May 2000 20:05:48 +0900 (JST) Received: from plum.ssr.bisd.hitachi.co.jp by bisdgw.bisd.hitachi.co.jp (8.9.3+3.2W/3.7W-bisdgw) with ESMTP id UAA19077; Fri, 19 May 2000 20:05:48 +0900 (JST) (envelope-from ume@bisd.hitachi.co.jp) Received: from localhost (IDENT:yUwXhSlivMgjZUxRfPpZ1qGGOdHzcNgJRaKsZIVxmB77B5ZtSgJlTgMGFvb0TXfM@localhost [::1]) by plum.ssr.bisd.hitachi.co.jp (8.10.1/3.7W-plum) with ESMTP id e4JB5lx90246; Fri, 19 May 2000 20:05:47 +0900 (JST) (envelope-from ume@bisd.hitachi.co.jp) Message-Id: <200005191105.e4JB5lx90246@plum.ssr.bisd.hitachi.co.jp> To: des@flood.ping.uio.no Cc: arch@freebsd.org Subject: Re: fetch(1) From: Hajimu UMEMOTO (=?iso-2022-jp?B?GyRCR19LXBsoQiAbJEJIJRsoQg==?=) In-Reply-To: References: <200005161852.e4GIqhF74521@peace.mahoroba.org> <200005162001.e4GK1bF75342@peace.mahoroba.org> X-Mailer: xcite1.20> Mew version 1.94.2 on XEmacs 21.1 (Bryce Canyon) X-PGP-Fingerprint: D3 3D D3 54 88 13 DE 22 3F 31 C4 4D A1 08 84 7B X-PGP-Public-Key: http://www.imasy.org/~ume/ume@bisd.hitachi.co.jp.asc X-URL: http://www.imasy.org/~ume/ X-OS: FreeBSD 4.0-STABLE Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 19 May 2000 20:05:47 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 29 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> On 19 May 2000 11:28:57 +0200 >>>>> des@flood.ping.uio.no (Dag-Erling Smorgrav) said: des> #define isftpreply(foo) (isdigit(foo[0]) && isdigit(foo[1]) \ des> - && isdigit(foo[2]) && foo[3] == ' ') des> + && isdigit(foo[2]) \ des> + && (foo[3] == ' ' || foo[3] == '\0')) Umm, I believe SPACE at foo[3] is not a optional text but required one. If actually foo[3] == '\0', it should be protocol error. RFC959 4.2. FTP REPLIES says: >Thus the format for multi-line replies is that the first line > will begin with the exact required reply code, followed > immediately by a Hyphen, "-" (also known as Minus), followed by > text. The last line will begin with the same code, followed > immediately by Space , optionally some text, and the Telnet > end-of-line code. > > For example: > 123-First line > Second line > 234 A line beginning with numbers > 123 The last line -- Hajimu UMEMOTO @ Business Solution System Development Div., Hitachi Ltd. E-Mail: ume@bisd.hitachi.co.jp ume@mahoroba.org ume@FreeBSD.org URL: http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 19 4:39:59 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id E5B5C37BA27; Fri, 19 May 2000 04:39:56 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id HAA04100; Fri, 19 May 2000 07:39:43 -0400 (EDT) Date: Fri, 19 May 2000 07:39:43 -0400 (EDT) From: Daniel Eischen To: Mike Smith Cc: Michael Schuster - TSC SunOS Germany , arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution In-Reply-To: <200005190650.XAA06921@mass.cdrom.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 Thu, 18 May 2000, Mike Smith wrote: > > 'scuse me for barging in - this sounds like what I know as "priority > > inheritance" (as one solution to the priority inversion problem). Are we > > talking of the same thing here? If no, what _is_ the difference? If yes, I > > could probably dig up one or two papers using these terms (we do at Sun, > > but that's not necessarily the place you're looking ... :-) > > Same thing, yes. I seem to recall there being some issues with it, too, > which might make for interesting reading. This is slightly off topic, but you can find some interesting articles, the Inside Solaris column by Jim Mauro in particular, at www.sunworld.com. Back issues are found at: http://www.sunworld.com/sunworldonline/common/swol-backissues-columns.html The following articles describe priorities, sleep/wakeup, turnstiles and priority inheritence, kernel synchronization primitives and locks: http://www.sunworld.com/sunworldonline/swol-07-1999/swol-07-insidesolaris.html http://www.sunworld.com/sunworldonline/swol-07-1999/swol-07-insidesolaris.html http://www.sunworld.com/sunworldonline/swol-08-1999/swol-08-insidesolaris.html http://www.sunworld.com/sunworldonline/swol-09-1999/swol-09-insidesolaris.html http://www.sunworld.com/sunworldonline/swol-10-1999/swol-10-insidesolaris.html http://www.sunworld.com/sunworldonline/swol-11-1999/swol-11-insidesolaris.html -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 19 5:16:38 2000 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id A0D9B37B65D for ; Fri, 19 May 2000 05:16:33 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id OAA63438; Fri, 19 May 2000 14:16:26 +0200 (CEST) (envelope-from des@flood.ping.uio.no) To: Hajimu UMEMOTO (=?iso-2022-jp?b?GyRCR19LXBsoQiAbJEJIJRsoQg==?=) Cc: arch@freebsd.org Subject: Re: fetch(1) References: <200005161852.e4GIqhF74521@peace.mahoroba.org> <200005162001.e4GK1bF75342@peace.mahoroba.org> <200005191105.e4JB5lx90246@plum.ssr.bisd.hitachi.co.jp> From: Dag-Erling Smorgrav Date: 19 May 2000 14:16:25 +0200 In-Reply-To: Hajimu UMEMOTO's message of "Fri, 19 May 2000 20:05:47 +0900" Message-ID: Lines: 16 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hajimu UMEMOTO ($BG_K\(B $BH%(B) writes: > >>>>> On 19 May 2000 11:28:57 +0200 > >>>>> des@flood.ping.uio.no (Dag-Erling Smorgrav) said: > des> #define isftpreply(foo) (isdigit(foo[0]) && isdigit(foo[1]) \ > des> - && isdigit(foo[2]) && foo[3] == ' ') > des> + && isdigit(foo[2]) \ > des> + && (foo[3] == ' ' || foo[3] == '\0')) > > Umm, I believe SPACE at foo[3] is not a optional text but required > one. If actually foo[3] == '\0', it should be protocol error. No, look at the code that uses the macro. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 19 10:39:23 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp09.phx.gblx.net (smtp09.phx.gblx.net [206.165.6.139]) by hub.freebsd.org (Postfix) with ESMTP id 4C5A137B6A2 for ; Fri, 19 May 2000 10:39:15 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp09.phx.gblx.net (8.9.3/8.9.3) id KAA46926; Fri, 19 May 2000 10:39:04 -0700 Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp09.phx.gblx.net, id smtpdT93cia; Fri May 19 10:39:00 2000 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id KAA29763; Fri, 19 May 2000 10:38:47 -0700 (MST) From: Terry Lambert Message-Id: <200005191738.KAA29763@usr02.primenet.com> Subject: Re: A new api for asynchronous task execution To: hasty@rah.star-gate.com (Amancio Hasty) Date: Fri, 19 May 2000 17:38:47 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), cp@bsdi.com (Chuck Paterson), wes@softweyr.com (Wes Peters), dfr@nlsystems.com (Doug Rabson), arch@FreeBSD.ORG In-Reply-To: <200005190000.RAA07951@rah.star-gate.com> from "Amancio Hasty" at May 18, 2000 05:00:35 PM X-Mailer: ELM [version 2.5 PL2] 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 > > There are better soloutions that permit resource risk, however, > > but they require that you be able to back completely out of a > > partial transaction, and retry the whole thing, e.g. continuing: > > Hmm... Given that in an OS scenario one may not be able to > restore the state of a partially committed transaction , I think > that transaction style processing is not appropiate for > exclusiveness of operations. Unless of course one is willing > to virtualize the machine states and then commit a fully > completed transaction which is somewhat what databases > such as Oracle do. Soft updates does precisely this, in an OS scenario. The requirement for backing out a directory modification that would result in an entry pointing to an uncommitted inode, when in the same block, there is another new entry that would point to a committed inode, is an example. In this case, the directory modification is "backed out" of the copy to be committed, but it remains in the soft updates synchronization clock for a later commit. Julian likens this to a "copy on write", but it's really "uncopy on commit". This approach permits you to create two files, "A" and "B", where the inode for "A" is committed to disk, the inode for "B" is pending commit to disk, "A" and "B" are in the same directory entry block, and you want to commit the directory entry for "A" because its dependencies have been satisfied, but not the one for "B", because its dependencies have not been satisfied. So you copy the directory entry block, zero the "B" entry, as if it had been deleted, and put the copy with the "A" - "B" contents earlier in the clock than the original with the "A" + "B" contents. The "A" - "B" version is committed to stable storage, and soft updates thus works. 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 May 19 10:44:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id DDFEC37BDFE for ; Fri, 19 May 2000 10:44:45 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id KAA19479; Fri, 19 May 2000 10:44:42 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpdAAAK7aG7L; Fri May 19 10:44:32 2000 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id KAA00232; Fri, 19 May 2000 10:44:28 -0700 (MST) From: Terry Lambert Message-Id: <200005191744.KAA00232@usr02.primenet.com> Subject: Re: Sparc & api for asynchronous task execution (2) To: wes@softweyr.com (Wes Peters) Date: Fri, 19 May 2000 17:44:27 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), cp@bsdi.com (Chuck Paterson), dfr@nlsystems.com (Doug Rabson), arch@FreeBSD.ORG In-Reply-To: <3924DA18.392990EA@softweyr.com> from "Wes Peters" at May 19, 2000 12:07:20 AM X-Mailer: ELM [version 2.5 PL2] 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: > > > > > }I didn't realize that every function call involved a fault on the sparc > > > }architecture - that sounds pretty nasty. > > > > > > Actually every function call doesn't cause a fault, every > > > time you overflow/underflow the current set of register windows causes a > > > fault. (Perhaps what you meant). This means that calling a function > > > from the bottom most function will cause two faults, one for going down > > > and one eventually as you go up. > > > > > > This makes going up and down when you don't overflow > > > very fast at the expense of when you add to the total depth. > > The register window sizes weren't picked willy-nilly. The SPARC default > size is 7 windows, chosen after months of analyzing every M68K SunOS > program they could get their hands, including compiled C, Pascal, LISP, > and Fortran programs. > > I suspect C++ and Java probably skew these stats a little. This might > account for the 8 windows in more modern SPARC processors. Please watch your attributions; I said none of this. The truncated pat that included my comments was merely a reference to the 1991 University of Washington paper on SPARC register windows and user space threading, which has a good discussion of SPARC register windows. PS: Not to give you a hard time, but this stuff is archived, and I am always prepared to defend/acknowledge-incorrectness for everything I say, but not for what others say. 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 May 19 11: 2:41 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 1DFAB37C0C2; Fri, 19 May 2000 11:02:32 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id LAA20432; Fri, 19 May 2000 11:02:29 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpdAAANjaOZN; Fri May 19 11:02:22 2000 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id LAA00644; Fri, 19 May 2000 11:02:21 -0700 (MST) From: Terry Lambert Message-Id: <200005191802.LAA00644@usr02.primenet.com> Subject: Re: A new api for asynchronous task execution To: michael.schuster@germany.sun.com (Michael Schuster - TSC SunOS Germany) Date: Fri, 19 May 2000 18:02:21 +0000 (GMT) Cc: wes@softweyr.com (Wes Peters), msmith@FreeBSD.ORG (Mike Smith), cp@bsdi.com (Chuck Paterson), dfr@nlsystems.com (Doug Rabson), arch@FreeBSD.ORG In-Reply-To: <3924E25D.DEB9F987@germany.sun.com> from "Michael Schuster - TSC SunOS Germany" at May 19, 2000 08:42:37 AM X-Mailer: ELM [version 2.5 PL2] 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 > > > > No, speaking of temporarily elevating the priority of a process holding > > > > a lock to the highest priority of all processes blocking on the lock. > > > > > > You could call this "priority lending" so that the rest of us understand > > > what you're talking about. 8) > > > > The only system I've ever worked on that implements them refer to > > them as inversion-safe or inversion-proof semaphores. I've never seen > > another name, including "priority lending", in any literature or > > article on the subject. > > 'scuse me for barging in - this sounds like what I know as "priority > inheritance" (as one solution to the priority inversion problem). Are we > talking of the same thing here? If no, what _is_ the difference? If yes, I > could probably dig up one or two papers using these terms (we do at Sun, > but that's not necessarily the place you're looking ... :-) The problem is called "priority inversion" in the literature. The abstract description states that the problem can occur when a high priority process can not run because it requires a resource held by a low priority process, which does not run to the point it releases the resource, due to it's priority. In both cases, a possible soloution is to temporarily raise the priority of the low priority process so that it can rn to the point it releases the resource. If the resource itself has reservations made by a high priority process, then the operation is called "priority inheritance", since by virtue of the low priority process using the resource, it will inherit the priority of the highest priority process holding a reservation on the ersource (in intention-mode locking, this is a SIX lock: Shared, Intention eXclusive). When the resource is released, the priority of the lower priority process is reduced to its previous value. If the resource does not have a reservation pending, and is allocated to a low priority process, then when a high priority process needs the resource, the low priority priority process is "lent" the high priority process' priority _until it releases the resource_. This operation is called "priority lending". In the general case, priority inheritance is more efficient than priority lending, IFF the resource is going to be repeatedly released and reacquired. IFF the resource is _not_ going to be released and reacquired, then one can delay, perhaps permanently, the need for a lower priority process to obtain higher priority. This permits priority lending to be more efficient, in that the processes are "truer to their intended priorities" than they might otherwise be. Priority inheritance is generally associated with Djikstra's "Banker's Algorithm", which is a prereservation of all needed resources. Priority lending is not; since Djikstra's algorithm has some potentially significant negative effects on concurrency (#1 wants "A" then "B", #2 wants "B", #2 could run to completion before #1 asks for "B", but can not run because "B" has been precomitted to #1 to avoid deadlock), priority lending is to be preferred for most cases (an exception is for resources which will be held for long periods of time, or repeatedly held and released, at which point the in-band cost of lending is once per transaction, whereas the priority inheritance setup costs can be amortized over all transactions). A FreeBSD example similar to "priority inheritance" is when a process opens /dev/io, it gains access to the I/O bus. When it closes /dev/io, this access is revoked. A FreeBSD example similar to "priority lending" is seen in the "FASTINTR" processing. 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 May 19 11: 4:53 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.cdrom.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id 4DC5137BDCC; Fri, 19 May 2000 11:04:51 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id LAA09036; Fri, 19 May 2000 11:05:26 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200005191805.LAA09036@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Doug Rabson Cc: Wes Peters , Mike Smith , Chuck Paterson , arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution In-reply-to: Your message of "Fri, 19 May 2000 09:46:24 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 May 2000 11:05:26 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The only system I've ever worked on that implements them refer to > > them as inversion-safe or inversion-proof semaphores. I've never seen > > another name, including "priority lending", in any literature or > > article on the subject. > > Anyway, whatever we choose to call it, the BSD/OS mutex does have support > for priority lending. Can someon that's familiar with both make a comparison between the BSD/OS mutex and the Solaris 7 'turnstile' mutex implementation? I'm getting the impression that the two are in fact extremely similar... -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 19 12:12:45 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id 171D237B7B0; Fri, 19 May 2000 12:12:40 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id NAA11320; Fri, 19 May 2000 13:12:38 -0600 (MDT) Message-Id: <200005191912.NAA11320@berserker.bsdi.com> To: Mike Smith Cc: Doug Rabson , Wes Peters , arch@freebsd.org Subject: Re: A new api for asynchronous task execution From: Chuck Paterson Date: Fri, 19 May 2000 13:12:38 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG }Can someon that's familiar with both make a comparison between the BSD/OS }mutex and the Solaris 7 'turnstile' mutex implementation? I'm getting }the impression that the two are in fact extremely similar... The short answer is that they are reasonably similar. Solaris has features which we (BSD/OS) plan on adding, but don't effect the users of the mutex. It was a conscious decision to delay adding these features until we had more data about exactly how they should be implemented. We still haven't got to that stage. BSD/OS locks require that the type of lock be passed in when the lock is acquired or released. This removes a test for the common case. Actually looking a little more at the Solaris doc they get rid of the test in the common case and pay an even high price for spin locks. BSD/OS hangs the processes/threads which have blocked trying to acquire a mutex right off the mutex. In Solaris the queues appear to be else where, although they may only be logically else where. I can't really tell, but this really isn't the important part. What is important is that they have segregated mutexs. When acquiring or releasing a non spin mutex is contested a spin mutex is acquired while sorting things out. In the case of BSD/OS this a single mutex. I'm really don't know how adequate or better how inadequate this is. It unlikely to scale above 4, and I really don't know if it will make it that far. But it does make things much simpler and while the kernel isn't stable simplicity matters. If, more likely when, we find excessive contention on this mutex then we will add more. At this point you need to select a mutex to use. The grouping of the turnstile does this for Solaris. Going beyond a single scheduling mutex will cause us to do something similar. We have been using the term priority propagation. When a process blocks on a mutex the running priority is propagated to the holder of the mutex, if the holder is at a lower priority. As far as I can tell it is identical to the Solaris term priority inheritance. When I left Sun this had yet to be implemented but the need for it was certainly understood. Solaris's default mutexs are adaptive mutexs. Adaptive mutexs may spin for a bit before giving up and task switching. Currently BSD/OS's default mutexs task switch immediately when trying to acquire a mutex held by another task. This also is something we will almost certainly change as soon as we get some data about what sort of heuristics to apply. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 19 12:22:54 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.cdrom.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id 73F6F37BF92 for ; Fri, 19 May 2000 12:22:49 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id MAA09426; Fri, 19 May 2000 12:23:53 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200005191923.MAA09426@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Chuck Paterson Cc: arch@freebsd.org Subject: BSD* mutex summary In-reply-to: Your message of "Fri, 19 May 2000 13:12:38 MDT." <200005191912.NAA11320@berserker.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 May 2000 12:23:53 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thanks for the summary here; this helps put things in context in combination with Sun's publications on the topic. One item: > We have been using the term priority propagation. When a process > blocks on a mutex the running priority is propagated to the > holder of the mutex, if the holder is at a lower priority. As > far as I can tell it is identical to the Solaris term priority > inheritance. When I left Sun this had yet to be implemented but > the need for it was certainly understood. As Terry made it clear, this is "priority lending" in the common lexicon. Given the recent exercise over the proposed kernel thread architecture, where after much discussion and the invention of a great deal of new terminology we basically reinvented scheduler activations (described in a 10 year old paper), I think that cleaving to existing terminology is probably a good idea. After all, none of this is rocket science, and I don't think we need to kid ourselves that this hasn't already been done before. Where there's material elsewhere that we can benefit from, whether it's just terminology or whether it's code complete, it's worth taking advantage of someone else's sweat and tears. 8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 19 12:51:10 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id DAA4037BFBE; Fri, 19 May 2000 12:51:06 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id NAA11660; Fri, 19 May 2000 13:51:05 -0600 (MDT) Message-Id: <200005191951.NAA11660@berserker.bsdi.com> To: Mike Smith Cc: arch@freebsd.org Subject: Re: BSD* mutex summary From: Chuck Paterson Date: Fri, 19 May 2000 13:51:05 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I believe in that in general inheritance and lending are use interchangeably. That's not true either. I think inheritance is in general used to describe both situations. The following quote from a Inside Solaris by Jim Mauro. Chuck Priority inversion describes a scenario where a higher-priority thread is unable to run due to a lower-priority thread holding a resource it needs (for example, a lock). The Solaris kernel addresses the priority inversion problem in its turnstile implementation, providing a priority inheritance mechanism, where the higher-priority thread can will its priority to the lower-priority thread holding the resource it requires. The benefactor of the inheritance, the thread holding the resource, will now have a higher scheduling priority, and thus get scheduled to run sooner so it can finish its work and release the resource, at which point the thread is given its original priority back. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 19 12:57:50 2000 Delivered-To: freebsd-arch@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 103C737BFEC; Fri, 19 May 2000 12:57:42 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id PAA10743; Fri, 19 May 2000 15:00:47 -0500 (CDT) (envelope-from jlemon) Date: Fri, 19 May 2000 15:00:47 -0500 From: Jonathan Lemon To: Chuck Paterson Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: BSD* mutex summary Message-ID: <20000519150047.F66114@prism.flugsvamp.com> References: <200005191951.NAA11660@berserker.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200005191951.NAA11660@berserker.bsdi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, May 19, 2000 at 01:51:05PM -0600, Chuck Paterson wrote: > I believe in that in general inheritance and lending are > use interchangeably. That's not true either. I think inheritance > is in general used to describe both situations. The following quote > from a Inside Solaris by Jim Mauro. I believe they are interchangable terms for the same thing, with "priority inheritance" being most widely used. Vahalia's text, for example, treats them this way. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 19 13: 2:41 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 3A1C937BF7F; Fri, 19 May 2000 13:02:37 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id QAA39228; Fri, 19 May 2000 16:02:35 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 19 May 2000 16:02:34 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Mike Smith Cc: Chuck Paterson , arch@freebsd.org Subject: Re: BSD* mutex summary In-Reply-To: <200005191923.MAA09426@mass.cdrom.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 Fri, 19 May 2000, Mike Smith wrote: > As Terry made it clear, this is "priority lending" in the common lexicon. In all the literature I've been reading, ``priority inheritence'' has been the term use to describe what I think we're talking about -- i.e., processes/tasks inheritting higher priorities whenthey hold a resource a higher priority process is blocked on. This was certainly the term used in my realtime/distributed systems class at CMU a few years ago, so is fairly widely accepted. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 19 13:24:21 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.cdrom.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id 197FE37B5FA for ; Fri, 19 May 2000 13:24:15 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id NAA09668; Fri, 19 May 2000 13:25:18 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200005192025.NAA09668@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Chuck Paterson Cc: arch@freebsd.org Subject: Re: BSD* mutex summary In-reply-to: Your message of "Fri, 19 May 2000 13:51:05 MDT." <200005191951.NAA11660@berserker.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 May 2000 13:25:18 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I believe in that in general inheritance and lending are > use interchangeably. That's not true either. I think inheritance > is in general used to describe both situations. The following quote > from a Inside Solaris by Jim Mauro. I'll leave Terry to defend the nomenclature that he fairly carefully outlined, since it's a more accurate instance of what I've generally understood by the various terms. The distinction between "lending" and "inheritance" is subtle and often the line is irrelevant, but the two processes described are indeed quite different and have signficantly different tradeoffs. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 19 18:39:35 2000 Delivered-To: freebsd-arch@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id E7CFE37B552; Fri, 19 May 2000 18:39:31 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Fri, 19 May 2000 21:39:30 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Dag-Erling Smorgrav Cc: Hajimu UMEMOTO , arch@FreeBSD.ORG Subject: Re: fetch(1) 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 19 May 2000, Dag-Erling Smorgrav wrote: > - for (p--, i = 0; i < 6; i++) { > - p++; /* skip the comma */ > + for (i = 0; *p, i < 6; i++, p++) > addr[i] = strtol(p, &p, 10); Right now with that change, the code will merrilly skip along addr[], setting the members to 0 and incrementing i to 6. While this is not especially harmful, you should probably fix the "*p, i < 6" which is precisely equivalent to "i < 6" to be "*p != '\0' && i < 6". -- 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 Sat May 20 5:24:45 2000 Delivered-To: freebsd-arch@freebsd.org Received: from jasmine.hclt.com (jasmine.hclt.com [204.160.251.63]) by hub.freebsd.org (Postfix) with SMTP id 1456337B589 for ; Sat, 20 May 2000 05:24:32 -0700 (PDT) (envelope-from veliath@jasmine.hclt.com) Date: Sat, 20 May 00 18:15 IST Message-ID: <0005201816.AA08131@jasmine.hclt.com> From: veliath@jasmine.hclt.com To: arch@FreeBSD.ORG Subject: Re: BSD* mutex summary Content-Length: 3450 Content-Type: text Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Quoting Terry Lambert: u> If the resource itself has reservations made by a high priority u> process, then the operation is called "priority inheritance", since u> by virtue of the low priority process using the resource, it will u> inherit the priority of the highest priority process holding a u> reservation on the ersource (in intention-mode locking, this is a SIX u> lock: Shared, Intention eXclusive). When the resource is released, u> the priority of the lower priority process is reduced to its previous u> value. Isn't this akin to SVR4/MP kernels raising the spl before acquiring a lock, to the highest spl at which that lock is acquired? i.e. if an interrupt routine and a "base" routine share a lock, the base routine raises the spl to protect itself against the interrupt routine being scheduled on the same processor as it is. Ofcourse in this case the "reservations" are done at compile time. u> If the resource does not have a reservation pending, and is allocated u> to a low priority process, then when a high priority process needs u> the resource, the low priority priority process is "lent" the high u> priority process' priority _until it releases the resource_. This u> operation is called "priority lending". And isn't this what the Solaris documentation calls "priority inheritance"? I understand Solaris uses this to avoid having code that needs run only at low spls run at high spls unless necessary. [if at all they have the concept of "spl"s anymore - even internaly. Its not documented in their Driver Writers Guide.] Correct me if I am wrong. I am trying to understand whats being defined here. u> In the general case, priority inheritance is more efficient than u> priority lending, IFF the resource is going to be repeatedly released u> and reacquired. u> u> IFF the resource is _not_ going to be released and reacquired, then u> one can delay, perhaps permanently, the need for a lower priority u> process to obtain higher priority. This permits priority lending to u> be more efficient, in that the processes are "truer to their intended u> priorities" than they might otherwise be. I do not understand this. Could you describe a scenario where "priority inheritance" (your definition) is more efficient than "priority lending" (again your definition). Thank you, veliath u> Priority inheritance is generally associated with Djikstra's u> "Banker's Algorithm", which is a prereservation of all needed u> resources. u> u> Priority lending is not; since Djikstra's algorithm has some u> potentially significant negative effects on concurrency (#1 wants "A" u> then "B", #2 wants "B", #2 could run to completion before #1 asks for u> "B", but can not run because "B" has been precomitted to #1 to avoid u> deadlock), priority lending is to be preferred for most cases (an u> exception is for resources which will be held for long periods of u> time, or repeatedly held and released, at which point the in-band u> cost of lending is once per transaction, whereas the priority u> inheritance setup costs can be amortized over all transactions). u> u> u> A FreeBSD example similar to "priority inheritance" is when a process u> opens /dev/io, it gains access to the I/O bus. When it closes u> /dev/io, this access is revoked. u> u> u> A FreeBSD example similar to "priority lending" is seen in the u> "FASTINTR" processing. u> u> u> Terry Lambert u> terry@lambert.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat May 20 10:43:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from sharmas.dhs.org (c62443-a.frmt1.sfba.home.com [24.0.69.165]) by hub.freebsd.org (Postfix) with ESMTP id B3C3E37B563 for ; Sat, 20 May 2000 10:43:11 -0700 (PDT) (envelope-from adsharma@sharmas.dhs.org) Received: (from adsharma@localhost) by sharmas.dhs.org (8.9.3/8.9.3) id KAA02898; Sat, 20 May 2000 10:42:48 -0700 Date: Sat, 20 May 2000 10:42:48 -0700 From: Arun Sharma To: Wes Peters Cc: arch@FreeBSD.ORG Subject: Re: Sparc & api for asynchronous task execution (2) Message-ID: <20000520104248.A2866@sharmas.dhs.org> References: <200005182045.NAA21595@usr08.primenet.com> <3924DA18.392990EA@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <3924DA18.392990EA@softweyr.com>; from Wes Peters on Fri, May 19, 2000 at 12:07:20AM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, May 19, 2000 at 12:07:20AM -0600, Wes Peters wrote: > > > This makes going up and down when you don't overflow > > > very fast at the expense of when you add to the total depth. > > The register window sizes weren't picked willy-nilly. The SPARC default > size is 7 windows, chosen after months of analyzing every M68K SunOS > program they could get their hands, including compiled C, Pascal, LISP, > and Fortran programs. Times have changed. If you have looked at stack traces in Mozilla or Konqueror, they easily go 40 calls deep. The real problem with sparc register windows is flushing of the stack on every system call. Clever software tricks can avoid this on IA-64. -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat May 20 11:37:25 2000 Delivered-To: freebsd-arch@freebsd.org Received: from peace.mahoroba.org (peace.calm.imasy.or.jp [202.227.26.34]) by hub.freebsd.org (Postfix) with ESMTP id 9DAF437B53A for ; Sat, 20 May 2000 11:37:19 -0700 (PDT) (envelope-from ume@mahoroba.org) Received: from localhost (localhost [::1]) by peace.mahoroba.org (8.10.1/3.7W-peace) with ESMTP id e4KIWYc06469; Sun, 21 May 2000 03:32:34 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sun, 21 May 2000 03:32:34 +0900 (JST) Message-Id: <200005201832.e4KIWYc06469@peace.mahoroba.org> To: des@flood.ping.uio.no Cc: arch@FreeBSD.ORG Subject: Re: fetch(1) In-Reply-To: References: <200005122016.e4CKGtF38185@peace.mahoroba.org> X-Mailer: xcite1.20> Mew version 1.94.2 on Emacs 20.6 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= X-PGP-Public-Key: http://www.imasy.org/~ume/publickey.asc X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.org/~ume/ X-OS: FreeBSD 5.0-CURRENT Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Hajimu UMEMOTO (=?ISO-2022-JP?B?GyRCR19LXBsoQiA=?= =?ISO-2022-JP?B?GyRCSCUbKEI=?=) X-Dispatcher: imput version 20000228(IM140) Lines: 20 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> On 15 May 2000 10:58:40 +0200 >>>>> Dag-Erling Smorgrav said: > http://www.imasy.or.jp/~ume/ipv6/FreeBSD/libfetch-ipv6.diff.gz > http://www.imasy.or.jp/~ume/ipv6/FreeBSD/fetch-20000508-ipv6.diff des> The patches look fine - I don't have enough experience with IPv6 to des> judge their technical merits, but they're relatively low-impact and I des> assume that you know what you're doing. If you commit the libfetch des> part of the patches, I'll merge the fetch part and put up a new des> tarball. Thank you. I just committed my IPv6 support code. Please merge fetch part. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat May 20 14: 1: 7 2000 Delivered-To: freebsd-arch@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 2234637B70D; Sat, 20 May 2000 14:01:01 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Sat, 20 May 2000 17:01:00 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: James Howard Cc: Chris Costello , arch@FreeBSD.ORG, committers@FreeBSD.ORG Subject: Re: Review for basename(3) and dirname(3) implementation. 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 Thu, 18 May 2000, James Howard wrote: > On Thu, 18 May 2000, Chris Costello wrote: > > > I've implemented an XPG4.2-conforming version of basename(3) > > and dirname(3), along with reentrant basename_r(3) and > > dirname_r(3) functions. > > > > I would like some feedback for this code and hopefully it can > > be committed soon. > > > > The new files are available at > > http://people.FreeBSD.org/~chris/basename/ -- libgen.h to go in > > src/include and the rest to go in lib/libc/gen. > > Kill bin/12960 and bin/12962 if and when these go through. My revised editions are in http://people.FreeBSD.org/~green/. I have verified they operate according to specification, and they now are in proper ANSI style as well as a few other things... > Jamie -- 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