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."