[SAGA-RG] blocking/nonblocking I/O on files?

[Andre Merzky]

Hi John, 

Quoting [John Shalf] (Aug 29 2007):
> 
> On Aug 29, 2007, at 11:19 AM, Andre Merzky wrote:
> >Hi,
> >Ole and Hartmut raised the point that the attribute
> >interface on files is actaully useless.
> >
> >Formerly, we had a number of attributes on files defined -
> >in the latest version of the spec, only one remaines:
> 
> Where did they all go?

I digged a little in CVS history, and as far as I can see,
more attribs were never specified on the file.  


> >'Blocking'.  That atgtribute however does not make much
> >sense, as we have explicit versions for sync and async file
> >I/O.
> 
> My original recollection of the "attributes" interface was that it  
> allowed us to smuggle in file behaviors that would otherwise be  
> accessed via the ioctl() and fcntl() interfaces.  Perhaps we haven't  
> found any ioctls that we really need right now, but you should keep  
> the attributes interface around so that you can add such capabilities  
> in an as-needed basis.

Right, that was the motivation I think.  However, we cleaned
a lot of placeholders over time which had no explicit use
cases - the API is big enough as it is...  If the need for
an IOCTL like interface arises, we can add them again in a
later version.

> That is certainly the case with ioctl()  (you  
> rarely use that interface, when when you need it, that capability is  
> essential).
> 
> >Yes, yes, sync/async and blocking/non-blocking is not
> >exactly the same, but (a) the difference is small for our
> >use cases AFAICS (thats different for streams), and (b) the
> >spec does not define the behaviour for blocking/non-blocking
> >files anyway.
> 
> I thought it was assumed that the POSIX spec for blocking/nonblocking  
> (which would be enabled via ioctl()) would be in effect.

That would basically only mean that 'EAGAIN' is returned if
no/not enough data are avialable on a non-blocking
read/write, right?

You can do that in SAGA with an async read, and then wait
a finite time for that.  Also, a sync read can legally
return less data then requested, which again is similar to
non-blocking reads.

Yes, I know, its not the same really, but seems ok for the
use cases we have.  IMHO, async I/O is much more useful in
remote systems than non-blocking I/O.  

Do you have use cases for remote file I/O which rely on the
ops beeing no-blocking?

Cheers, Andre.


-- 
"XML is like violence: if it does not help, use more."