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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 1225 Actions

    Problem Report Number 1225
    Submitter's Classification Minor System Fault
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0427
    Raised 1970-01-01 08:00
    Updated 2003-03-13 08:00
    Published null
    Product Standard Internationalised System Calls and Libraries Extended (UNIX 95)
    Certification Program The Open Brand certification program
    Test Suite VSU version 4.0.2
    Test Identification base/fpoll 12
    Problem Summary PG4U.00040 A MSF is requested because the IUT poll() implementation fails to report file descriptors available for writing high priority band data prior to the first write of such data on the fd.
    Problem Text
    Note: Please refer to PG4U.00039.
    The original reference number is req.4.U.00138

    We respectfully disagree with the consultants reasons for refusing
    the original MSF request. Following is our rebuttal to the argument.

    If our argument is not sufficently persuasive, our next step is to request
    an X/Open interpretation based on the incomplete description of POLLWRBAND
    as described below. The question being is the incomplete text inclusion
    of the SVR4.2 description an oversight? Alternatively, perhaps this should
    be done simultaneously?

    ---------------------- Our rebuttal ---------------------------------

    > The following is the response from X/Open concerning poll 12. Do you wish
    > to rebut their argument? If so (or if not) I wish to hear your argument...
    >
    > We believe that developers of significant client/server
    > applications may rely on the high priority IPC band discussed
    > here. Implementation will probably be via generic I/O handlers
    > that will always poll() fds before writing output. Requiring
    > the application identify the first write (let alone the firt
    > high priority write) and treat it specially seems unrealistic to
    > us.

    Suppose poll() is implemented in the way you specify, i.e., poll()
    returns POLLWRBAND even when the bands have never been used. If band 1
    messages have never been used, then obviously the band 1 is not
    flow-controlled yet, therefore poll must return POLLWRBAND. Similarly,
    if band 2 messages have never been used, then obviously the band 2 is
    not flow-controlled yet, therefore poll must return POLLWRBAND.
    Remember, poll() system call can not specify which band you're
    interested in.

    Suppose the "client/server application" you mentioned above uses high
    priority band 1 message (i.e. band = 1). Suppose the application has
    sent a lot of band 1 messages, and the band 1 messages are
    flow-controlled now. At this moment, poll() would still return
    POLLWRBAND according to your interpretation because the application can
    still write band 2 through band 255 messages. I don't think this poll()
    is useful. In practice, poll() would not give you any good information
    on POLLWRBAND.

    In the above case, what the application really wants to know was whether
    the band messages it is using (i.e. band 1) is flow-controlled or not.
    It has no interest on the other bands. That is why SVR4.2 defines
    POLLWRBAND of poll() as the following:

    POLLWRBAND
    Priority data (priority band > 0) may be written. This event
    only examines bands that have been written to at least once.

    -----------------------------------------------------------------------------

    Here's a general argument:

    XPG4v2 says:

    POLLWRBAND
    Priority data (Priority band greater then 0) may be written.

    There are three types of messages:

    - Normal messages
    - Priority band messages (or called banded messages)
    - High-priority messages

    There are 255 priority bands (band 1 through band 255). It is extremely
    rare for applications to use all the bands. In most cases, applications
    only use priority band messages of band 1, in addition to normal
    messages and high priority messages.

    Suppose an applications doesn't use all the bands, but use only band 1.
    Then, what the application really wants to know is whether it can send
    band 1 messages. When the band 1 is flow-controlled on its write side,
    poll() should NOT return POLLWRBAND.

    If we take the XPG4v2's approach, however, even if the band 1 is
    flow-controlled, poll() would need to return POLLWRBAND because the
    other bands (band 2 through band 255) are not flow-controlled (actually
    not used at all). This is useless.

    That is why SVR4.2 defines POLLWRBAND of poll() as the following:

    POLLWRBAND
    Priority data (priority band > 0) may be written. This event
    only examines bands that have been written to at least once.

    ---- Yoshihiro


    ---------------------- original argument below ----------------------

    The poll()s implementation fails to report file descriptors available
    for writing high priority band data prior to the first write of such
    data on the fd.

    This fault should have little user impact, as it only occurs when
    POLLWRBAND is polled for before any out of band data has been
    written. Any polls for POLLWRBAND once out of band data has been
    written will work correctly, which is sufficient for the
    flow-control purpose the flag is intended for. We will fix this
    defect at the first opportunity, but do not feel it is a
    significant problem for our customers.
    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 with
    priority band greater than 0 can be written to the
    file descriptor specified by the fd member without
    blocking and set the POLLWRBAND flag in the
    corresponding revents member when found.
    PREP: Create two streams
    PREP: Create a pipe
    PREP: Determine if pipe is a stream
    PREP: Create a pipe
    PREP: Determine if pipe is a stream
    TEST: poll returns number for selected file descriptors
    ERROR: poll returned incorrect value
    Expected 2
    Received 0
    12 FAIL

    Review Information

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

    The submitter may or may not have valid comments about
    the description of POLLWRBAND being complete. But they
    seem to miss the crucial point regarding this request.

    The submitter states the original issue as

    The poll()s implementation fails to report file descriptors
    available for writing high priority band data prior to the
    first write of such data on the fd.

    This means that applications which use the example we described
    in our original response will never be able to write out of band
    messages.

    This issue is the subject at hand, not the suitability of POLLWRBAND
    to provide meaningful information about flow control for multiple
    priority bands.

    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