On Wed, Aug 07, 2002 at 10:10:29PM +0200, Oskar Sandberg wrote:
> On Wed, Aug 07, 2002 at 06:56:43AM -0700, G?ran Thyni wrote:
> > It probably does NOT work at all!!
> 
> I'm afraid the final statement is probably the truth here.

Great,
I checked-in early to get comments so I am happy you looked at it.

> In order for the Buffer implementation to do it's job, it needs to
> support "sliding locks". That is to say: if somebody starts reading a
> buffer while is being written to, you need to make sure that the reader
> can read as much as possible, but that it stays behind the writer by
> wait()ing when it caches up.

One approach would be the simplistic way to get
a atomic write:
- Write to tmp-file then "File.rename()"

at least on unix an open file is refer to by inodes so
as long as the file is already open you can read until
you close it, changes in the directory has no effect.

Still it may be best (but not necessary) to block multiple
writer.

Problem with this approach?
What about non-unix systems, anyone?

> It also needs to do vice versa: if somebody
> starts overwriting a buffer while it is being read from, you need to make
> sure that the writer can write as much as possible but then wait()s when
> it caches up with the reader.

Do we ever rewrite keys? Not CHK keys?
I will have to read up on the key type and their function.

regards,
-- 
G?ran





_______________________________________________
devl mailing list
devl at freenetproject.org
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to