This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Tue, Sep 23, 2008 at 4:28 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote: > Hi again, Chris , >> This patch solves the issue with solution B. >> > I say, for gcc4.4.0, let's go ahead with Plan B. We can certainly > improve things later. > > Only, please confirm that the additional exports are in any case needed > if we want a separate monotonic clock, regtest again the patch vs > current mainline and commit it. > > Thanks again, > Paolo. > This issue is also discussed in DR 887 (not public yet I don't think, check the lwg active issues list post San Fran). I spoke with Howard H. and the intent of the wording is to allow user-defined clocks to be used with condition variables given that cond var's may only work with some "known" clock type(s). If a user calls wait_* with an unknown clock type, then it must first be synced to the known clock. We can currently say that condition_variable's known clock is system_clock since we don't have the pthread_condattr_setclock backend stuff in gthreads to allow the use of monotonic_clock. If a user supplies a monotonic clock, it will just sync it to the system_clock and all is good (except for a small sync issue if there's a large delay between the two now() calls during syncing resulting in the function exiting potentially later than intended. Howard thinks this is unavoidable no matter how you specify it). Attached updated patch. Tested x86_64 (with --enable-clock-gettime=rt). Ok for mainline? Chris
Attachment:
cond_var.patch.txt
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |