From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <6386745.9NEQHczKvd@coil> References: <6c7d84f203a2cc4f3427e177e34fa9d9@brasstown.quanstro.net> <6386745.9NEQHczKvd@coil> From: Dan Cross Date: Thu, 30 Aug 2012 19:54:31 +0530 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] rc's shortcomings (new subject line) Topicbox-Message-UUID: b421d902-ead7-11e9-9d60-3106f5b1d025 On Thu, Aug 30, 2012 at 7:11 PM, dexen deVries wrote: > On Thursday 30 of August 2012 15:35:47 Dan Cross wrote: >> (...) >> Your example of running multiple 'grep's in parallel sort of reminded >> me of this, though it occurs to me that this can probably be done with >> a command: a sort of 'parallel apply' thing that can run a command >> multiple times concurrently, each invocation on a range of the >> arguments. But making it simple and elegant is likely to be tricky. > > now that i think of it... > > mk creates DAG of dependences and then reduces it by calling commands, going > in parallel where applicable. > > erik's example with grep x *.[ch] boils down to two cases: > - for single use, do it simple & slow way -- just run single grep process for > all files > - but when you expect to traverse those files often, prepare a mkfile > (preferably in a semi-automatic way) which will perform search in parallel. > > caveat: output of one grep instance could end up in the midst of a /line/ of > output of another grep instance. The thing is that mk doesn't really do anything to set up connections between the commands it runs.