Re: [PATCH, v3] Bringing <mutex> and <condition_variable> up to spec.

["Chris Fairles" <chris dot fairles at gmail dot com>]

On Wed, Jul 23, 2008 at 2:20 PM, Benjamin Kosnik <bkoz@redhat.com> wrote:
>
>> Attached patch brings <mutex> and <condition_variable> up to spec
>> (n2691 WD) given that <chrono> is now in.
>
> Excellent, thanks. This looks good to me.
>
>> I included stubs for timed_mutex and timed_recursive_mutex but when I
>> went to attempt a basic implementation I noticed that the gthread API
>> doesn't include pthread_mutex_timedlock and/or pthread_cond_timedwait
>> if they're available. Should it?
>
> Yes.
>
>> Other general questions,
>> Is the thread API in the current working draft stable enough to
>> complete the implementation?
>
> I believe it should be attempted, and I would encourage you to work on
> it.
>
>> Are there required additions/changes to backend thread-support code
>> (like gthreads)?
>
> Yes, you'll have to hack the gthread layer to add some of the
> required functionality. I posted some preliminary work on this 20080318,
> but then only merged in the changes that didn't require new
> functionality (ie, <mutex> minus time.)
>
> So, in this general form:
> http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00057.html
>
> But for the rest of this stuff. :) Also, Mark Mitchell needs to review
> and OK before checkin.
>
> I had been holding off on the preliminary bits for <thread> for this
> same reason.
>
> -benjamin
>

Just want to check if I'm on the right track with the gthread backend
modifications (see attached patch for changes). I'm trying not to
touch too much objc stuff because I'm not at all familiar with it.

One question about _POSIX_TIMEOUTS. The *timedlock's are available if
its defined, in the gthr-single, should the wrapper return -1
indicating its not supported or should there be no def'n at all? (Same
sort of question for gthr-posix.c although there I just don't define
the stub w/p _POSIX_TIMEOUTS).

Chris

Attachment: gthr-patch.txt
Description: Text document