Don Cragun <don.cragun@Sun.COM> wrote, on 29 May 2008:
>
> Here is my proposed resolution for XSH ERN #238.
> This completes my second of two action items from the May 1,
> 2008 conference call.
[snip]
> The following changes make the handling of SIGXFSZ consistent with the
> way SIGPIPE is handled in stdio and non-stdio functions, and regularizes
> the wording in EFBIG error clauses:
>
> 1. Add a new paragraph after P582, L20983:
Line number should be 20093.
> If the request would cause the file size to exceed the soft
> file size limit for the process and there is no room for any
> bytes to be written, the request shall fail and the
> implementation shall generate the SIGXFSZ signal for the
> thread.
> as the new last paragraph of the aio_write DESCRIPTION section with
> XSI shading.
>
> 2. Change the wording on P583, L20120-21023 from:
> The following condition may be detected synchronously or
> asynchronously:
> [EFBIG] The file is a regular file, aiobcp->aio_nbytes is
> greater than 0, and the starting offset in
> aiobcp->aio_offset is at or beyond the offset maximum
> in the open file description associated with
> aiocbp->aio_fildes.
> in the aio_write ERRORS section to:
> The following conditions may be detected synchronously or
> asynchronously:
> [EFBIG] The file is a regular file, aiobcp->aio_nbytes
> is greater than 0, and the starting position is
> greater than or equal to the offset maximum in
> the open file description associated with
> aiocbp->aio_fildes.
> XSI [EFBIG] The file is a regular file, aiobcp->aio_nbytes
> XSI is greater than 0, and there is no room for any
> XSI bytes to be written at the starting position
> XSI without exceeding the file size limit for the
> XSI process. A SIGXFSZ signal shall also be sent to
> XSI the thread.
> with shading as indicated by the margin markings.
I think if these two EFBIG cases are explicitly allowed to be detected
synchronously, then the other case (exceeding max file size) should
be included here as well:
[EFBIG] The file is a regular file, aiobcp->aio_nbytes
is greater than 0, and there is no room for any
bytes to be written at the starting position
without exceeding the implementation-defined
maximum file size.
> 1. Add to end of P805, L26824 (2nd fclose() EFBIG error):
> A SIGXFSZ signal shall also be sent to the thread.
> with XSI shading.
Interesting numbering convention :-)
> 2. Add to end of P844, L28042 (2nd fflush() EFBIG error):
> A SIGXFSZ signal shall also be sent to the thread.
> with XSI shading.
>
[snip]
> 8. Change:
> "In addition to the errors returned by the lio_listio()
> function,"
> on P1222, L40349 to:
> "In addition to the errors returned by the aio_read() and
> aio_write() functions,"
> in the lio_listio() ERRORS section.
I think I can see what you're trying to do here, but this change
doesn't work. In order for the new text to make sense there would
need to be an earlier reference to errors returned by aio_read()
and aio_write(). One could be added, but I think it would be
simpler just to delete the text "In addition to the errors returned
by the lio_listio() function". Alternatively, I think the other
lio_listio() changes are sufficient without making any change here.
> 9. Change:
> "The error codes that can be set are the same as would be set
> by a read() or write() function,"
> on P1222, L40355-40356 to:
> "The error codes that can be set are the same as would be set
> by an aio_read() or aio_write() function,"
> in the lio_listio() ERRORS section.
This is a little misleading; I think it should say:
"The error codes that can be set are the same as would be set
if the I/O operation had been initiated by an aio_read() or
aio_write() function,"
> 10. Delete the EFBIG error condition on P1223, L40360-40363 in the
> lio_listio() ERRORS section. (This is covered by EFBIG errors
> in the aio_write() ERRORS section.)
>
> 11. Delete the EOVERFLOW error condition on P1223, L40365-40368 in the
> lio_listio() ERRORS section. (This is covered by the EOVERFLOW
> error in the aio_read() ERRORS section.)
The ECANCELED error (L40358) is also covered by the new reference to
aio_read/aio_write and can be deleted.
--
Geoff Clare <g.clare@opengroup.org>
The Open Group, Thames Tower, Station Road, Reading, RG1 1LX, England
|