Date: Wed, 08 Mar 95 15:35:49 -0800 From: Bakul Shah <bakul@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 Message-ID: <199503082335.PAA24741@netcom22.netcom.com> In-Reply-To: Your message of "Wed, 08 Mar 95 09:51:18 MST." <9503081651.AA00888@cs.weber.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503082335.PAA24741>