From owner-freebsd-bugs Wed Mar 8 15:58:59 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA26819 for bugs-outgoing; Wed, 8 Mar 1995 15:58:59 -0800 Received: from netcom22.netcom.com (bakul@netcom22.netcom.com [192.100.81.136]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id PAA26813 for ; Wed, 8 Mar 1995 15:58:57 -0800 Received: from localhost by netcom22.netcom.com (8.6.10/Netcom) id PAA24741; Wed, 8 Mar 1995 15:35:53 -0800 Message-Id: <199503082335.PAA24741@netcom22.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 09:51:18 MST." <9503081651.AA00888@cs.weber.edu> Date: Wed, 08 Mar 95 15:35:49 -0800 From: Bakul Shah Sender: bugs-owner@FreeBSD.org Precedence: bulk > One drawback, though: team make some assumptions about signals and > pipes that are bad. Such as? > While it is higher performance than ddd when > it works, you could argue that it isn't even writen in C. 8-). You mean you don't like PierCarlo Grandi's use of cpp :-) Actually it is a whole sight better than the original Bourne shell's! > The problems with its assumptions manifest on MP Sun machines, > among others, by causing "broken pipe" messages instead of dumping > output. I have used team on MP SGI machines where it worked fine, and not MP Sun machines but this surprises me. team reads (multiple times if necessary) from the input until enough data is received to fill up blocksize buffer or until EOF. Similarly for output. Perhaps broken pipe is associated with something else? I am not doubting what you say but I'd like to know under what circumstances team does not work. > In any case, team is insufficient for the same reason the ft filter > isn't working, which is that the ft driver require that the program > that is writing to it get its process quantum sufficiently frequently > that it doesn't miss it's smallest timing window (subquanta). The same thing can happen with a uni-process program too. > Actually, a filter that used multiple outstanding async reads and > used async writes to dump the data would probably have significantly > higher performance than team because it would avoid context switching. But can you have *multiple* outstanding async reads on the same file/device from a *single* process? I didn't think so. > I suggest "super team" so it can have a cool name like "steam". Well, such program is not using a `team' (of processes) so any derivation of team would be even less appropriate. (`team' itself is not at all descriptive of what it does). Bakul Shah