Date: Wed, 08 Mar 95 18:29:20 -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: <199503090229.SAA18798@netcom21.netcom.com> In-Reply-To: Your message of "Wed, 08 Mar 95 18:18:04 MST." <9503090118.AA03354@cs.weber.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503090229.SAA18798>