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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 1137 Actions

    Problem Report Number 1137
    Submitter's Classification Specification problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0339
    Raised 1970-01-01 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.2
    Test Identification CAPIbase/fgetmsg 40
    Problem Summary PG4U.00133 A PIN is requested because the submitter claims streams need not support queueing more than one high priority message at a time.
    Problem Text
    This request for 14 day review by TgBase is for getmsg #41 and
    getpmsg #42.

    The XPG5 XSH spec is in conflict with historical SysV streams
    implementations. The XPG5 spec on page 34 states the following:

    "High priority messages are always placed at the head of the queue
    but after any other high-priority messages already in the queue."

    SysVr3 and SysVr4 historical practices keep only the first high-priority
    message in the queue when additional ones are processed. From SysVr4
    Programmer's Guide: Streams page A-18 (Appendix A) states:

    "The Stream head will allow only one M_PCPROTO message to be placed
    in its read queue at a time. If an M_PCPROTO message is already
    in the queue another arrives, the second message is silently
    discarded and its message blocks freed."
    Test Output
    TEST CASE: getmsg

    TEST PURPOSE #41
    After a message is put back on the queue as a result
    to a call to int getmsg(int fildes, struct strbuf
    *ctlptr, struct strbuf *dataptr, int *flagsp) which
    consumes the control part of a high priority, if a
    priority message already exists on the STREAM head, a
    subsequent call to getmsg or getpmsg shall retrieve
    the higher-priority message before retrieving the
    remainder of the message that was put back.
    PREP: Create a pipe
    PREP: Determine if pipe is a stream
    INFO: Pipes are not STREAMs on this implementation
    PREP: Open 2 spx drivers and create pipe
    PREP: Set O_NONBLOCK on read end of STREAM
    PREP: Put a high priority message on the STREAM
    PREP: Put a second high priority message
    PREP: Read the control part of the message
    TEST: The second high prioriy message is retrieved first by getmsg
    ERROR: Data not put in buffer
    Expected 72('H')
    Received 68
    41 FAIL

    TEST CASE: getpmsg

    TEST PURPOSE #42
    After a message is put back on the queue as a result
    to a call to int getpmsg(int fildes, struct strbuf
    *ctlptr, struct strbuf *dataptr, int *bandp, int
    *flagsp) which consumes the control part of a high
    priority, if a priority message already exists on the
    STREAM head, a subsequent call to getmsg or getpmsg
    shall retrieve the higher-priority message before
    retrieving the remainder of the message that was put
    back.
    PREP: Create a pipe
    PREP: Determine if pipe is a stream
    INFO: Pipes are not STREAMs on this implementation
    PREP: Open 2 spx drivers and create pipe
    PREP: Set O_NONBLOCK on read end of STREAM
    PREP: Put a high-priority message on the STREAM
    PREP: Put a second high priority message
    PREP: Get the control portion of the first message from STREAM
    TEST: The second high priority message is retrieved first
    ERROR: Data not put in buffer
    Expected 72('H')
    Received 68
    42 FAIL


    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    We recommend this request be refused.

    Historical practice is not normative, the XSH wording quoted is not
    new to XSH5 and we believe its use was clearly intended.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    This request should go for a 14 day review.

    Review Type Expert Group Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    The Base Working group recommends the request be refused. The text in
    XSH is indeed in conflict with historical practise, and a corrigenda will
    be issued. However, what the tests are attempting to verify is proper
    STREAMS behavior. When the control block of the first high-priority
    message is consumed, the remaining part of the message (the data) is
    no longer considered to be a high-priority message, but rather merely
    M_DATA to be put on the queue. Thus the arriving high-priority message
    is the only one present, and should be retrieved.

    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