Re: io assumptions

On Thu, 2002-12-05 at 21:10, Henrik Nordstrom wrote:

> Is it the OS that makes the callback as a result of a async OS.Open()
> beeing able to complete immediately.

Yes.
 
> As UFS is syncronous it can signal open/create I/O errors by refusing
> the operation (returning NULL). I have no opinion if this is good or bad
> and have no problem if this is changed to signal the error via the
> callback.
>
> But I still believe that it is a good thing that the storeio driver can
> refuse the operation early on without having to first create and return
> a SIO handle.

Granted, and I've already modified my approach to accomodate this.
 
> > What design corner? I'm not trying to be difficult here, I just am not
> > clear on the issue.
>
> What I am objecting is not the change to signal errors always via the
> callback, but the change to not return a SIO until the open/create
> operation has completed.

Ok. Cool.

> > Ok. This is fine, and fits with my 'speculative reads or writes'
> > assumption above. I think we need to be more clear about data loss
>
> If the callback signals error then the object has to be assumed
> non-existing and all data lost.

Ok. That's clear enough for me :}.
 
> > What about this (thinking out loud):
> > storeClose() just signals that the core doesn't want the object anymore.
> > if we reference count the object instead, it will detect when it's not
> > wanted, and it can just quietly vanish. It's up to the store layers io
> > object to clean up properly.
>
> storeClose() may well be implemented by reference counts if you like but
> I like to see a "commit" operation in case of swapouts to signal that
> all of the object has been stored.

Ok. Will think some more on this. No rush after all.

> The difference between the file_callback and close_callback needs to be
> explained better in the API docs. Seems to be missing completely.

Yep :}. Thanks for your patience here.

Rob