[prev in list] [next in list] [prev in thread] [next in thread] 

List:       coreutils-bug
Subject:    bug#6643: [PATCH] sort: fix a bug with sort -u and xmemcoll0,
From:       Chen Guo <chen.guo.0625 () gmail ! com>
Date:       2010-07-16 10:07:12
Message-ID: AANLkTilKj0wmMnZy_3YjzOIoVxsautK70_RQ2dYejf2h () mail ! gmail ! com
[Download RAW message or body]

> Chen, can you please verify that "sort -u" does not access the same
> line from multiple threads, even saved lines?  If it does, then even this patch
> is not enough: we would need to alter write_bytes so that it does not
> modify its argument at all.

I just went over the code, pretty big nostalgia trip :-)

write_unique's saved line has already worked its way up to the root node
of the tree; that's to say whatever sorting is to be done on it has already
been done. Thus, none of the merging threads will ever call compare on
it, since they would only do work on remaining un-fully-sorted, yet-to-be-
output lines. Also, only one call to write_unique will ever occur at one
time on one buffer.

The external merge process also makes use of a saved line, but that part
is sequential I believe. Joey's external merge patch might play some games
with it, but I've only skimmed their code. We'll have to cross that bridge
when we get there.




[prev in list] [next in list] [prev in thread] [next in thread]