From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Tue, 28 Aug 2012 16:34:10 EDT." <8ee568439e1855124564ecf0e83ac2b3@kw.quanstro.net> References: <68ce90976b22bdb0929ccccafef4b7d0@kw.quanstro.net> <3330200.XJjoRb8JbZ@blitz> <5538fcd345a73fc294c6ee568f2fcdb4@kw.quanstro.net> <8ee568439e1855124564ecf0e83ac2b3@kw.quanstro.net> Date: Tue, 28 Aug 2012 15:46:32 -0700 From: Bakul Shah Message-Id: <20120828224632.547BAB827@mail.bitblocks.com> Subject: Re: [9fans] rc's shortcomings (new subject line) Topicbox-Message-UUID: b224b476-ead7-11e9-9d60-3106f5b1d025 On Tue, 28 Aug 2012 16:34:10 EDT erik quanstrom wrote: > my knee-jerk reaction to my own question is that making it easier > and more natural to parallelize dataflow. a pipeline is just a really > low-level way to talk about it. the standard > grep x *.[ch] > forces all the *.[ch] to be generated before 1 instance of grep runs on > whatever *.[ch] evaluates to be. Here the shell would have to understand program behavior. Consider something like 8l x.8 y.8 z.8 ... This can't be parallelized (but a parallelizable loader can be written). May be you can define a `par' command (sort of like xargs but invokes in parallel). echo *.[ch] | par -1 grep x > but it would be okay for almost every use of this if *.[ch] were generated > in parallel with any number of grep's being run. > > i suppose i'm stepping close to sawzall now. Be careful!