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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 0579 Actions

    Problem Report Number 0579
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0183
    Raised 1970-01-01 08:00
    Updated 2003-03-13 08:00
    Published null
    Product Standard Commands and Utilities V2 (UNIX 95)
    Certification Program The Open Brand certification program
    Test Suite VSC version 4.1.5
    Test Identification POSIX.cmd/kill/kill.ex 19
    Problem Summary PG4C.00094 This was refused because it is a duplicate. Use TSD4C.00189 instead.
    Problem Text
    I would like to reopen the discussion on the following resolution as we feel
    that the proposed resolution is in error and show our reasoning below.
    If the group still feel unsure of our reasoning then this should
    be passed on for a POSIX.1 interpretation as this is a POSIX requirement
    adopted by the X/Open specifications.

    > Proposed Resolution 1170/168 (seq 1865)
    > ---------------------------------------
    > This resolution resulted in a lengthy discussion. Some comments were as
    > follows:
    > o This is a problem with threads implementations; i.e., it worked before.
    > o Suggest using O_APPEND with >>.
    > o Suggest this is a bug in the implementation.
    > o SCO maintain they are covered by the POSIX statements quoted.
    > o XPG4 V2 doesn't contain any multi-processor material.
    > o This must be fixed in Eastwood.
    > o General agreement that this is not a spec bug, although disagreement
    > about whether the spec is silent on this issue.
    > o Resolution should reference XSH4 V2, Section 2.4.1, Pages 32-34 re
    > synchronisation between handles.
    > o The group decided to reject the C code and look at the shell script
    > (kill test 19).
    >

    We have been further studying the text referenced above Section 2.4.1, Pages 32-34
    and feel that this text is not applicable to the situation outlined in the original
    resolution request. The title of the section is "Interaction of File Descriptors
    and Standard I/O Streams" and on page 33 in the second paragraph this is
    made clearer:

    "The result of the function calls involving any one handle (the active handle) are
    defined elsewhere in this document, but if two or more handles are used, and any one
    of them is a stream, their actions must be coordinated as described below. If this is not
    done, the result is undefined"

    In the sample code below neither handle is a stream.

    The reference to uniprocessor and multiprocessor is also misleading in the resolution
    request as the situation described can happen on a uniprocessor system but is
    more visible on multiprocessor system.

    The whole section of XSH 2.4.1 is a word for word reprint if the POSIX 8.2.3 section
    titled "Interactions of Other FILE-Type C Functions"

    This then makes the POSIX rationale for write more relevent as we feel it does not
    conflict with any normative text. On page 270 it says:

    "POSIX.1 does not specify behavior of concurrent writes to a file from multiple
    processes. Applications should use some form of concurrency control"

    Furthermore, even if XSH 2.4.1 / POSIX.1 8.2.3 are relevant, not all
    instructions listed in these sections are followed by the application
    in question. In particular,

    "All activity by the application affecting the file offset on the first handle
    must be suspended until it again becomes the active file handle."

    casts some doubt on the proposed resolution since the problem in question occurs
    only when a write(2) by one process overlaps a write(2) by another. Since
    write(2) affects the file offset, this application is not following the quoted
    instruction in the section that has been cited in the resolution. If concurrent
    write(2)s were prevented by the application (i.e., if activity by the
    application affecting the file offset on the first handle were suspended
    while the second handle was active), this problem would not occur
    in our system, regardless of the types of handles used.

    We feel that if the group still feel that the referenced section is relevant
    and that the application in question is faithfully following all instructions
    in that section, then confirmation should be obtained by requesting a
    POSIX.1 interpretation, as it is POSIX material that is being interpreted
    here and we have a different interpretation.

    This POSIX.1 interpretation as well requesting the applicability of
    the text described above may well want to clarify what the expected
    POSIX.1 behaviour in the following cases:


    Two processes, A and B, both call write() at the same moment, when
    the file offset has value X. Process A succeeds in writing N bytes
    to the file. Process B now gets to write. The question is, does
    POSIX specify whether B writes from offset X or from offset (X + N)?


    Process A starts to write N bytes at offset A. However, due to
    record locking it goes to sleep. Now process B, lseek and write
    M bytes at offset B. Now the offset is B+M. When process A wakes up
    should it write at offset A or B+M?

    Process A Process B
    write N bytes
    offset = f_offset
    sleep due to record lock

    lseek B
    write M bytes
    f_offset = B + M;

    wakeup
    offset = f_offset
    or the old offset?



    The relevence to the kill_out_19_1 test is that streams need not be part of
    the implementation of the shell and redirected shell output and so a waiver
    based on the above argument will be applicable (either permanent or temporary).





    Original Resolution Request
    _______________________________________________________________________
    +Resolution Request ref : 1170/168
    Publication : XSH4 V2
    Interface : concurrent writes to a shared file
    Date requested : 7.22.96
    Status : Open
    _______________________________________________________________________
    [Request text starts]


    We would ask for a Base WG resolution on the following subject, following
    a difference of opinion with the VSC4 testsuite maintainers over the
    subject of concurrent writes to a file from multiple processes sharing
    a file descriptor.

    The VSC test has a script that when invoked redirects its stdout to a file
    (kill_out_19_1). This script then invokes a number of other processes
    that don't redirect their stdout but inherit this redirection from
    the parent. In the case above we believe all the child processes inherit
    the same file table entry and this we think is the problem resource.

    On uniprocessor systems all the data is written but no data seems
    to be lost but on mp systems we start to have some problems. To eliminate
    the shell from the issue a small test program has been written
    that shows what we are seeing.

    #include <sys/types.h>
    #include <sys/stat.h>
    #include <sys/signal.h>
    #include <fcntl.h>

    int fd;
    char str[20];

    trap() {
    write(fd, str, strlen(str));
    exit(0);
    }

    main() {
    if ((fd = open("/tmp/T", O_WRONLY|O_CREAT|O_TRUNC, 0666)) < 0) {
    perror("open\n");
    exit(1);
    }
    signal(SIGTERM, trap);
    child("1");
    child("22");
    child("333");
    strcpy(str, "4444");
    sleep(3);
    kill (0, SIGTERM);
    sleep(3);
    }

    int
    child(char *msg) {
    int pid;

    if ((pid = fork()) < 0) {
    perror("fork");
    exit(2);
    }
    if (pid == 0) {
    write(fd, ".", 1);
    strcpy(str, msg);
    sleep(20);
    }
    sleep(1);
    }

    The output is a "." for each running process and then catching the signal
    from a kill 0 shows each process outputting a number of digits.

    On a uniprocessor box we get the following from various runs
    Test Output
    520|58 1 18297 1 1|Assertion #19 (A): kill 0
    520|58 1 18297 1 11|Expected TERM_0, TERM_1, TERM_2 and TERM_3 in this file:
    520|58 1 18297 1 12|Contents of kill_out_19_1:
    520|58 1 18297 1 13|TERM_0
    520|58 1 18297 1 14|TERM_3
    520|58 1 18297 1 15|TERM_2
    220|58 1 1 20:49:00|FAIL

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    We continue to disagree with submitters on this issue and recent
    POSIX discussion is supportive of our disagreement.

    However a recent ruling regarding this issue exists.

    To avoid the confusion duplicate rulings regarding the same issue
    might cause we recommend this request be refused and the
    submitter use TSD4C.00189 instead.

    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