site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com async io is there in Tiger. look at: bsd/sys/aio.h bsd/kern/kern_aio.c Mea culpa. It is the case that aio.h already documents that the O_DSYNC argument is not supported. Sorry about that. I don't have a copy of POSIX handy to confirm this, but the O'Reilly book "POSIX.4: Programming for the Real World" says (page 343): "fdatasync() may be implemented as a call to fsync(), in which case fdatasync() will be no faster than fsync()." This implies that it might be legal under POSIX for Apple to do as the quoted text says above for the aio_fsync() case. If that is the main difference between Apple's implementation and POSIX compliance for this symbol (_POSIX_ASYNCHRONOUS_IO), and if the quoted sentence above were true, then it would be nice if Apple could put the needed shims into headers/source so that the implementation could become POSIX compliant for that symbol. Since my source code does check for the standard POSIX symbol, as part of trying to be clean portable code, that tweak would eliminate the need for me to special case the Apple platform (which is all "nice to have", rather than absolutely essential). It's just one of those strings you don't really want to pull. 8-(. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On Jul 28, 2005, at 3:38 PM, Ran Atkinson wrote: On 28 Jul 2005, at 16:54, Terry Lambert wrote: On Jul 28, 2005, at 9:28 AM, Jerry Cottingham wrote: On Jul 28, 2005, at 8:57 AM, Ran Atkinson wrote: I have some existing UNIX-based (i.e. not Carbon/Cocoa) software that uses the POSIX Asynchronous I/O interfaces. These seem not to be present in Darwin (MacOS X 10.4), at least if unistd.h is to be believed. POSIX requires that _POSIX_ASYNCHRONOUS_IO be defined to 200112L in <unistd.h> *ONLY* if you fully support all aspects of the API features for that option group. The MacOS X implementation supports all important aspects of the [AIO] feature group, but not all possible aspects. In particular, we don't support the O_DSYNC argument to aio_fsync(). I considered doing that, when I went to set the <unistd.h> value, but there are a couple of implementational problems with a "just do it" approach: (1) It's actually possible to write code that's sensitive to whether or not it's implemented that way (trust me: I went out of my way to write some). (2) There's specific reference to _POSIX_SYNCHRONIZED_IO when you do this, so that would have to be there, too. (3) If we defined a value for O_DSYNC now, we'd have to pick its value very, very carefully - it's used by other APIs, e.g. open(2), which would have to behave correctly, and which would need to have it not collide with other flags definitions. For right now, I think we'll have to stick with "Use the _POSIX_ASYNCHRONOUS_IO test in general, and test for MacOS X, too, if you aren't using O_DSYNC". This approach will keep working if or when we support _POSIX_ASYNCHRONOUS_IO fully. This email sent to site_archiver@lists.apple.com