[One item you failed to mention: asynchronous I/O allows subsequent operations to execute before the I/O completes. I think you're doing a bit of circular reasoning, i.e. you assume that operations following the I/O call do not execute until the I/O gives us its return (complete) value and then proceed to assert that the I/O is therefore synchronous according to how you know synchronous I/O to work ... QED.
I made no assumptions that subsequent I/O operations must wait before starting another one. That's your inference.
Please clariofy your terminology. The red-hilited parts ambiguous. The "operations" could referring only to I/O operations, or "operations" could mean execution of user-written code after the return, such as comparisons of the return value in an if statement, or assignment of the return value to a variable. The async I/O system can accept subsequent I/O operations, but that means that user code runs and requests those I/O operations. That user code consists of "operations" (CPU instructions) that are not I/O operations. So I'm unclear on exactly what you're criticizing.
The instructions (operations) after the async function returns are outside the control of the I/O system. Any value returned by an async function belongs to the instructions that execute after the return.
Your following statements deal strictly with how Apple implements the writeToFile:atomically: method. I have no knowledge of what they do "under the covers" ... do you?
I asser that the design of that method is inherently synchronous. There is no way for it to tell the code that executes after a return about any async completion.
You keep implying that a design can be asynchronous even if there is no separate mechanism for indicatiing completion. I assert that such a thing is impossible. Please explain how an API exactly like the
writeToFile:atomically: method could be implemented in an asynchronous manner, without adding a separate completion mechanism. This is not just a random challenge, it is the very heart of the disagreement.
True, but there is nothing we know from the semantics of the method that tells us that the following code waits for that completion. If it waits, then the I/O is synchronous ... if it proceeds without waiting then the I/O is asynchronous.
I assert that it can't maintain the contract described in the docs, and be asynchronous. There is no way for it to report completion.
The return value (a boolean) reports success or failure. That value cannot be determined until completion. Therefore, the method cannot return that value and also be asynchronous; I asser that it's a logical impossibility.
You clearly believe that it's possible for this method to be asynchronous, but you have yet to show how that's possible. It could be done by adding an async completion mechanism, but that's adding something that the method currently doesn't have.
So if you can show how this method could have asynchronous completion and still fulfill it's documented contract, I'd like to see it. Basically, you keep saying that the method could be asynchronous and we don't know, and I keep saying that there is a logical contradiction if the method is asynchronous and returns success/fail as a boolean.
Not true! That behavior is precisely what asynchronous I/O allows!
I'm not contesting that. I'm contesting that a method with this exact API can be asynchronous
at all. I see no way it can be done. Please describe how it can be done.
Once again, you are assuming that the following code waits for the I/O to complete. How do you know that to be true?
No I'm not. I'm assuming that the following code gets a YES/NO boolean that indicates success. The only logical way that boolean can indicate success is if the I/O operations have completed.
If the method returns a success/fail boolean, then that logically precludes any asynchronous completion. Completion must be synchronous in order for the method to return a success/fail boolean.
It is logically impossible to have an incomplete I/O operation and a boolean that indicates success, because success cannot be determined until the I/O operations are actually completed.
Again, you seem to be asserting that the method CAN return an indicator of success while also being asynchronous (separate completion). Please explain exactly how that can be achieved. I'm not looking for how Apple implements it. I'm only looking for a logical explanation that resolves what I see as a logical contradiction.
I've never said nor did I mean to imply a two step (YES/NO and a later revision of that completion result).
That's exactly how I interpreted your earlier assertions about subsequent operations. See the above where I request clarification.
Again, there is nothing in the semantics of the writeToFile:atomically that tell me when the completion value is given to me ... before or after the following code executes.
Yes there is.
C guarantees that when a function returns, any value being returned belongs to the caller. If the returned type is a reference type (pointer), then the called function may keep a pointer, and some asynchronous code could possibly alter the pointed-at data. If the returned type is a simple type (int, float, double, etc.) then the called function can no longer alter the returned value. Since C only supports those two kinds of types (simple types and reference types), those two rules cover the entire C type space; C has no other types.
Objective-C methods are essentially a specific kind of C function. Read the Objective-C Runtime reference docs for how the message-send operation resolves a method-signature into a function pointer.
Since the method in question returns a simple type (boolean), there is no way the method can do anything except return the boolean completion value, thus completely giving up control to the caller. Since it must return a value that can only be determined after completion, the method must logically be synchronous. That is, it must wait for completion so it has a value it can return.
Since you seem to think otherwise, please explain how the method would be able to return a valid success/fail boolean without having waited for completion. Again, this is the heart of the disagreement, which you have not yet explained.