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

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 1670 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 1670.

Report 1670 Actions

    Problem Report Number 1670
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0474
    Raised 2000-10-09 08:00
    Updated 2003-03-13 08:00
    Published null
    Product Standard Internationalised System Calls and Libraries Extended V2 (UNIX 98)
    Certification Program The Open Brand certification program
    Test Suite VSU version 5.0.4
    Test Identification CAPIbase/poll 12
    Problem Summary PG4U.00177 This IR claims that the pts driver doesn't have to queue the band 1 message "because it is not flow-controlled".
    Problem Text
    Test #12 expects POLLWRBAND to be set after writing band 1 message once.
    However, the pts (PTY-slave side) driver doesn't queue this message (it
    doesn't have to because it is not flow-controlled) and pass it to master-side.
    The CAE-spec (page 597) and STREAMS programmer's guide on poll() says that
    "This event only examines bands that have been written to at least once.
    "However, the testcase does not create the flow-control situation and so
    the pts queue does not create band queues. For the case of a PTY it is
    not possible for the slave-side to look at master-side stream-head read
    queue. The test has to flow-control the stream and then examine this event
    and it will work fine.
    Test Output
    TEST CASE: poll

    TEST PURPOSE #12
    A successful call to int poll(struct pollfd fds[],
    nfds_t nfds, int timeout) shall examine each element
    of the fds array for instances where the POLLWRBAND
    flag is set in the events member and data for a
    priority band greater than 0 which has been written to
    at least once can be written to the file descriptor
    specified by the fd member without blocking and shall
    set the POLLWRBAND flag in the corresponding revents
    member when found.
    PREP: Create two streams
    PREP: Open master pseudo tty
    PREP: Determine if pseudo tty is a stream
    PREP: Open slave side of pseudo tty
    PREP: Initialize the file descriptors and event structure
    TEST: poll returns correctly when no data has been written
    TEST: poll does not set POLLWRBAND when no data has been written
    PREP: Write band 0 data onto file descriptor
    TEST: poll returns correctly when only band 0 data has been written once
    TEST: poll does not set POLLWRBAND when only band 0 data has been written once
    PREP: Write band 1 data onto file descriptor
    TEST: poll returns correctly when band 1 has been written once
    ERROR: poll returned incorrect value
    Expected 1
    Received 0
    12 FAIL


    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    I can find nothing in the XSH5 specification to substantiate the claim
    that the pts driver doesn't have to queue the band 1 message "because
    it is not flow-controlled".

    The description of putpmsg() says simply "If /flags/ is set to MSG_BAND,
    then a message is sent in the priority band specified by /band/."
    (Forward-slashes added to indicate italics.) There is no indication
    that additional conditions might need to be satisfied, such as the
    application needing "to flow-control the stream", in order for
    messages in bands other than 0 to be sent.

    In any case, the requirement for poll() to examine a given band for the
    POLLWRBAND event is that the band has been "written to at least once".
    In the test a call to putpmsg() is made with the MSG_BAND flag set and
    with band=1. At the point when this call returns (with return value 0),
    band 1 then qualifies as having been "written to at least once",
    regardless of what the system has done with the message.

    It is recommended that this request is refused.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Rejected (REJ)
    Review Conclusion
    This request is refused.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority