Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • Shop

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 0327 Details

Help Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges

This page provides all information on Problem Report 0327.

Report 0327 Actions

    Problem Report Number 0327
    Submitter's Classification Specification problem
    State Resolved
    Resolution Permanent Interpretation (PIN)
    Problem Resolution ID PIN.X.0043
    Raised 1994-07-25 08:00
    Updated 2003-03-13 08:00
    Published 1994-07-26 08:00
    Product Standard Internationalised System Calls and Libraries (XPG4)
    Certification Program The Open Brand certification program
    Test Suite VSX4 version 4.2.3
    Test Identification POSIX.os/procprim/sigconcept 35
    Specification System Interfaces and Headers Issue 4
    Location in Spec See Problem Text
    Problem Summary PIN4.043 These tests fail because we complete certain kernel operations after a process has been stopped, which the test assumes cannot be completed, are interruptible and should fail (EINTR) when the thread i...
    Problem Text

    These tests fail because we complete certain kernel operations
    after a process has been stopped, which the test assumes cannot be
    completed, are interruptible and should fail (EINTR) when the thread
    is subsequently interrupted by a SIGCONT signal that is caught. Our
    kernel is designed to work on multi-nodal, multi-processor hardware
    and regards these operations as interruptible but asynchronous, much
    like IO operations, meaning they can complete even when a process is
    stopped.

    To explain, and taking the open() test as an example, the child
    process calls open() on a fifo (O_NONBLOCK clear, O_RDONLY set) and
    blocks because no process has the fifo open for writing. The process
    is then stopped. After a predefined interval, the parent process
    opens the other end of the fifo (O_NONBLOCK set, O_WRONLY set), and
    sends a SIGCONT signal to the child to wake it up.

    In the parent process, the open() call is expected to succeed because
    another process (the child) is attempting to open the fifo for reading.
    In the child, the open() is expected to fail (EINTR) as a result of
    sending the SIGCONT. This raises the following questions:

    i) Is it correct for the open() in the parent to succeed when in
    fact no process has the fifo open for reading. The child is
    in a transient state; that is, the open() thread is incomplete,
    unable to continue and is expected to fail (in this case).

    ii) Neither POSIX nor XPG4 define interactions between asynch-
    ronous kernel activities and process stopped status (although
    POSIX does contain warnings in various appendices). For
    example, if a process is waiting for an IO termination and
    is stopped, it is reasonable to assume that the IO termination
    will still be serviced; that is, the out-of-process or
    interrupt part of the thread is not affected by the stopped
    state of the process. Further to this, neither POSIX nor XPG4
    define which kernel operations may or may not be carried out
    asynchronously.

    In our case, rather more operations are processed
    asynchronously, as we have to synchronise multi-processor
    operation. In the case of the above open() request, because
    it cannot be satisfied immediately, the child process is
    suspended. It's interest in the opening of the fifo is
    recorded via state information in various data structures.
    When another process subsequently opens the other end of the
    fifo, the open for the first process (which may be located
    on a different node) is completed and the suspend status of
    the process is removed. Now when it subsequently receives a
    SIGCONT, signal processing proceeds as expected, except that
    when the open() eventually returns it has apparently opened
    the fifo successfully.

    We think this is a grey area and that a waiver should be granted for
    the following reasons:

    i) The state of stopped kernel threads is not defined by XPG4
    and should not be relied on by applications.

    ii) The entry for open() states that [EINTR] will be returned
    when a signal was caught during the open() function, but it
    does not define under what circumstances this may happen (for
    example, it does not indicate that an open request for a fifo
    can be interrupted).

    iii) Again in the entry for open(), XPG4 states that when opening a
    fifo with O_WRONLY and O_NONBLOCK set, the open() will return
    an error if no process currently has the file open for
    reading (in the above case, the VSX4 test assumes it will work
    even though the open for reading is incomplete).

    Other tests in this area fail for similar reasons using the fcntl(),
    read() and write() functions.
    Test Output

    /tset/POSIX.os/procprim/sigconcept/T.sigconcept 35 Failed

    function reported no interruption by stopping or SIGCONT signal
    fcntl() returned 0 errno 0, should return -1 errno 4
    function reported no interruption by stopping or SIGCONT signal
    read() returned 1 errno 0, should return -1 errno 4
    function reported no interruption by stopping or SIGCONT signal
    write() returned 1 errno 0, should return -1 errno 4
    function reported no interruption by stopping or SIGCONT signal
    open() returned 8 errno 0, should return -1 errno 4
    ******************************************************************

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    This was previously a temporary interpretation which has now been resolved.
    A permanent interpretation is recommended.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Permanent Interpretation (PIN)
    Review Conclusion
    A Permanent Interpretation is granted.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority