"A month of sundays ago Borislav Deianov wrote:"
> On Thu, Apr 13, 2000 at 01:54:26PM +0200, Peter T. Breuer wrote:
> > "A month of sundays ago Borislav Deianov wrote:"
> > > On Wed, Apr 12, 2000 at 11:51:25PM +0100, Alan Cox wrote:
> > > > Why do you want an atomic ps - nobody else has one
> > >
> > > solves the following problem: there currently is no way to atomically
> > > get more than 3K out of /proc, even if it's all in the same file. I
> >
> > You are mistaken on the latter point. There is no difficulty - once
> > you unravel the obscurantist coding. My version of the proconfig patch
> > commonly produces 12K of output from /proc/config, for example.
>
> I stand behind my statement that you cannot do this *atomically*. By
OK. I overlooked the "atomically". You would have to snapshot the data
and then dole it out to subsequent reads, and then ...
> this I mean a consistent view of the data, even if it changes while
> you are reading it. The reason is that you cannot hold a lock between
> calls to the ->read_proc method. You also cannot distinguish between
> calls made by different readers (you don't get an unique "struct file"
> for each reader like you do with devices).
I agree. This is the defect of the current code. You cannot really be
sure if you are seeing a repeat call for more data from the same
process, or you are seeing someone else starting to try and sneak
data from the file. You can be pretty sure if the offsets match up,
but not certain.
This is a general defect .. I would like to see block transactions
identified according to who asked for them, and a sequence number.
Then I could journal file level transactions reliably ...
> Of course this is not an issue for /proc/config since the data is
> static.
Not always.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:21 EST