From owner-freebsd-bugs Wed Mar 8 18:42:34 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA03051 for bugs-outgoing; Wed, 8 Mar 1995 18:42:34 -0800 Received: from netcom21.netcom.com (bakul@netcom21.netcom.com [192.100.81.135]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA03045 for ; Wed, 8 Mar 1995 18:42:33 -0800 Received: from localhost by netcom21.netcom.com (8.6.10/Netcom) id SAA18798; Wed, 8 Mar 1995 18:29:22 -0800 Message-Id: <199503090229.SAA18798@netcom21.netcom.com> To: terry@cs.weber.edu (Terry Lambert) cc: joerg_wunsch@uriah.heep.sax.de, henryk@gaja.ipan.lublin.pl, freebsd-bugs@FreeBSD.org Subject: Re: QIC-80 problem In-reply-to: Your message of "Wed, 08 Mar 95 18:18:04 MST." <9503090118.AA03354@cs.weber.edu> Date: Wed, 08 Mar 95 18:29:20 -0800 From: Bakul Shah Sender: bugs-owner@FreeBSD.org Precedence: bulk > Child process on another processor exits before the controlling process > on the first processor. I have asked the author of team to comment on this. Anyway, this problem should be easily fixable without breaking portability (e.g. by making sure none of the processes die until the process that first detected EOF on input receives back a STOP (or ABORT) message over its input command pipe). > Not on the same descriptor, that's true. You'd need to dup it. Okay, you can do this but how do you assure serializability? Say you are doing tar zcf - ... | steam > /dev/tape and steam dups fd 0 multiple times and starts async io on all of them. How can you figure out which fd has data from what offset? The offset where a read or write starts can really mess you up because you can not explicitly specify it with read/write. If you use LWP (nee threads) you have not gained much if any over team. Also, the overhead of context switch is pretty low these days: < 1ms, right? Even on a 250KB/s streamer tape, with 64KB block size you need no more than four switches for write (and four or more for reads). Go ahead and write (or urge others to write) a team replacement but I just wanted to point out that context switch is not a problem. If your system is so busy that it becomes a problem, a uni-process impl. will not really save you. Second, just because team breaks on Sun MP is no reason to throw it out on FreeBSD (well atleast until it runs on a MP system). > It would be using a team of threads of control in a single process > context instead of multiple processes or multiple threads. Okay, okay! Steam it is :-)