From 4c7b988525943f335efabfd5b40afad39dd2ac95 Mon Sep 17 00:00:00 2001 From: Gregory Nutt Date: Tue, 7 Oct 2014 08:34:10 -0600 Subject: [PATCH] Update some comments --- fs/aio/aio_read.c | 32 ++++++-------------------------- fs/aio/aio_write.c | 32 ++++++-------------------------- include/aio.h | 2 +- 3 files changed, 13 insertions(+), 53 deletions(-) diff --git a/fs/aio/aio_read.c b/fs/aio/aio_read.c index a4982532b1..33e6f4065c 100644 --- a/fs/aio/aio_read.c +++ b/fs/aio/aio_read.c @@ -158,6 +158,12 @@ static void aio_read_worker(FAR void *arg) * has been initiated or queued to the file or device (even when the data * cannot be delivered immediately). * + * If prioritized I/O is supported for this file, then the asynchronous + * operation will be submitted at a priority equal to a base scheduling + * priority minus aiocbp->aio_reqprio. If Thread Execution Scheduling is + * not supported, then the base scheduling priority is that of the calling + * thread (the latter is implemented at present). + * * The aiocbp value may be used as an argument to aio_error() and * aio_return() in order to determine the error status and return status, * respectively, of the asynchronous operation while it is proceeding. If @@ -233,32 +239,6 @@ static void aio_read_worker(FAR void *arg) * description associated with aiocbp->aio_fildes. * * POSIX Compliance: - * - The POSIX specification of asynchronous I/O implies that a thread is - * created for each I/O operation. The standard requires that if - * prioritized I/O is supported for this file, then the asynchronous - * operation will be submitted at a priority equal to a base scheduling - * priority minus aiocbp->aio_reqprio. If Thread Execution Scheduling is - * not supported, then the base scheduling priority is that of the calling - * thread. - * - * My initial gut feeling is the creating a new thread on each asynchronous - * I/O operation would not be a good use of resources in a deeply embedded - * system. So I decided to execute all asynchronous I/O on a low-priority - * or user-space worker thread. There are two negative consequences of this - * decision that need to be revisited: - * - * 1) The worker thread runs at a fixed priority making it impossible to - * meet the POSIX requirement for asynchronous I/O. That standard - * specifically requires varying priority. - * 2) On the worker thread, each I/O will still be performed synchronously, - * one at a time. This is not a violation of the POSIX requirement, - * but one would think there could be opportunities for concurrent I/O. - * - * In reality, in a small embedded system, there will probably only be one - * real file system and, in this case, the I/O will be performed sequentially - * anyway. Most simple embedded hardware will not support any concurrent - * accesses. - * * - Most errors required in the standard are not detected at this point. * There are no pre-queuing checks for the validity of the operation. * diff --git a/fs/aio/aio_write.c b/fs/aio/aio_write.c index db1daa2c6c..5ea2fe8e69 100644 --- a/fs/aio/aio_write.c +++ b/fs/aio/aio_write.c @@ -203,6 +203,12 @@ static void aio_write_worker(FAR void *arg) * has been initiated or queued to the file or device (even when the data * cannot be delivered immediately). * + * If prioritized I/O is supported for this file, then the asynchronous + * operation will be submitted at a priority equal to a base scheduling + * priority minus aiocbp->aio_reqprio. If Thread Execution Scheduling is + * not supported, then the base scheduling priority is that of the calling + * thread (the latter is implemented at present). + * * The aiocbp value may be used as an argument to aio_error() and * aio_return() in order to determine the error status and return status, * respectively, of the asynchronous operation while it is proceeding. @@ -280,32 +286,6 @@ static void aio_write_worker(FAR void *arg) * with aiocbp->aio_fildes. * * POSIX Compliance: - * - The POSIX specification of asynchronous I/O implies that a thread is - * created for each I/O operation. The standard requires that if - * prioritized I/O is supported for this file, then the asynchronous - * operation will be submitted at a priority equal to a base scheduling - * priority minus aiocbp->aio_reqprio. If Thread Execution Scheduling is - * not supported, then the base scheduling priority is that of the calling - * thread. - * - * My initial gut feeling is the creating a new thread on each asynchronous - * I/O operation would not be a good use of resources in a deeply embedded - * system. So I decided to execute all asynchronous I/O on a low-priority - * or user-space worker thread. There are two negative consequences of this - * decision that need to be revisited: - * - * 1) The worker thread runs at a fixed priority making it impossible to - * meet the POSIX requirement for asynchronous I/O. That standard - * specifically requires varying priority. - * 2) On the worker thread, each I/O will still be performed synchronously, - * one at a time. This is not a violation of the POSIX requirement, - * but one would think there could be opportunities for concurrent I/O. - * - * In reality, in a small embedded system, there will probably only be one - * real file system and, in this case, the I/O will be performed sequentially - * anyway. Most simple embedded hardware will not support any concurrent - * accesses. - * * - Most errors required in the standard are not detected at this point. * There are no pre-queuing checks for the validity of the operation. * diff --git a/include/aio.h b/include/aio.h index 3fd37e0f27..4f2345b30d 100644 --- a/include/aio.h +++ b/include/aio.h @@ -126,7 +126,7 @@ struct aiocb off_t aio_offset; /* File offset */ size_t aio_nbytes; /* Length of transfer */ int aio_fildes; /* File descriptor */ - int8_t aio_reqprio; /* Request priority offset */ + int8_t aio_reqprio; /* Request priority offset (not used) */ uint8_t aio_lio_opcode; /* Operation to be performed */ /* Non-standard, implementation-dependent data. For portability reasons,