Interpretations

Answering questions that may arise related to the meaning of portions of an IEEE standard concerning specific applications.

IEEE Standards Interpretations for IEEE Std 1003.1b™-1993 IEEE Standard for Information Technology - Portable Operating System Interfaces (POSIX(R)) - Part 1: System Application Program Interface (API) - Amendment 1: Realtime Extension [C language]

Copyright © 1996 by the Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue New York, New York 10016-5997 USA All Rights Reserved.

Interpretations are issued to explain and clarify the intent of a standard and do not constitute an alteration to the original standard. In addition, interpretations are not intended to supply consulting information. Permission is hereby granted to download and print one copy of this document. Individuals seeking permission to reproduce and/or distribute this document in its entirety or portions of this document must contact the IEEE Standards Department for the appropriate license. Use of the information contained in this document is at your own risk.

IEEE Standards Department Copyrights and Permissions 445 Hoes Lane, Piscataway, New Jersey 08855-1331, USA

Interpretation Request #1
Topic: async IO Relevant Sections: 6.7.4.2

1. Does the sigev_notify field need to be filled in the sig argument to lio_listio? The generic section on the aiocb (6.7.1.1) talks about the use of the sigev_notify field, however the section on lio_listio described different requirements using the same structure.
1b. If not, can it be filled in, and what is the behavior if for example the sigev_filed was set to SIGEV_NONE and the sigev_signo is non zero?
2. If a user puts valid values in the sigev_notify and sigev_signo fields in members of the aiocb list in a call to lio_listio() what happens? Are they ignored, do that happen as well as/instead of the event that is described by *sig argument.

Interpretation Response
1. The standard is clear that SIGEV_NOTIFY is ignored and a signal shall be sent. Conforming implementations must conform to this. This is different from the definition in section 3.3.1.2 and which the interpretation committee views as a defect in the standard. This fact is being refered to the sponsor for consideration. The interpretation committee suggests that applications might wish to consistently set SIGEV_NOFTIFY and SIGEV_SIGNO so that the application would continue to work correctly if the standard is changed.
2. The standard is clear that in the case raised, that a signal is generated at the completion of each i/o operation where sigev_signo is non-zero and one is also generated when the entire set of operations is completed. Conforming implementations must conform to this.

Rationale for Interpretation
None.