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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 2455 Actions

    Problem Report Number 2455
    Submitter's Classification Specification problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0667
    Raised 2005-04-13 00:02
    Updated 2005-04-15 19:18
    Published 2005-04-15 19:18
    Product Standard Internationalised System Calls and Libraries Extended V3 (UNIX 03)
    Certification Program The Open Brand certification program
    Test Suite VSTH
    Specification Base Definitions Issue 6
    Location in Spec flockfile / funlockfile
    Problem Summary Request for clarification of when locks need to be unlocked when
    locking thread exits without unlocking its locked files
    Problem Text The flockfile functions ( flockfile(), ftrylockfile(), and funlockfile
    () ) can be used to lock and unlock FILE* objects. They can be used
    to specify a sequence of I/O statements. This locking of files is
    much like the locking of mutexes. For example, when a file is locked
    by a thread, only that locking thread can operate on the file. The
    issue comes about when the locking thread exits without unlocking its
    locked files. The SUSv3 spec doesn't discuss whether or not the locks
    should be released when the locking thread calls pthread_exit().

    From a development perspective, we're not sure if this should be the
    responsibility of the user (to funlockfile() any locks before hand),
    or if our implementation should clean up the locks on pthread_exit()
    for the user.

    Thanks.
    Test Output We are not far enough in our development efforts to provide testsuite
    output.

    Review Information

    Review Type SA Review
    Start Date 2005-04-13 00:02
    Last Updated 2005-04-15 06:32
    Completed 2005-04-15 06:32
    Status Complete
    Review Resolution Rejected (REJ)
    Review Conclusion This PR is rejected as an INT, on procedural grounds. No test output
    is cited and it is in the form of a question rather than an assertion
    of alternative conformant behavior within the specification.

    The only relevant statement SA can find within the standard is this
    one on the pthread_exit page:

    "Thread termination does not release any application visible
    process resources, including, but not limited to, mutexes and file
    descriptors, nor does it perform any process-level cleanup
    actions, including, but not limited to, calling any atexit()
    routines that may exist."

    Our initial view is that this applies to FILE * locks obtained with
    flockfile(). Therefore it is the application's responsibility to
    ensure a thread releases the locks it holds before the thread
    terminates. However we suggest that the the submitter should address
    the question to the Austin Group directly.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority