Bruno Haible <br...@clisp.org> writes: > Pádraig Brady wrote: >> >> Of course this should only apply if its effect is not externally >> >> observable; if I have a very small file B and a very large file A, and I >> >> can get >> >> >> >> $ md5sum --threads A B >> >> abcdabcdabcdabcdabcdabcdabcdabcd B >> >> 12341234123412341234123412341234 A >> >> >> >> Then the option would be necessary. >> > >> > Good point Paolo. >> > I think that's another argument for splitting separate files to different >> > threads. >> >> Grr. An argument for _not_ splitting. > > Huh? You can make md5sum handle each file in parallel and still present the > output in the order given on the command line. To achieve this, each thread > will process one file and submit the result to the main thread before exiting. > The main thread will collect the results and output the result for argument > k only after the results for 1...k-1 have been collected and output.
The implementation of --threads for md5sum, that I posted some days ago, collects data for any file before flush it, still it can be improved to flush immediately when 1..k files are ready. Cheers, Giuseppe
