[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140831013111.GA12784@brightrain.aerifal.cx>
Date: Sat, 30 Aug 2014 21:31:11 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: C threads, v. 6.2
On Sat, Aug 30, 2014 at 08:30:34PM -0400, Rich Felker wrote:
> > For the C thread TU, what would be the mechanics for them to call one
> > of the (aliased) pthread functions?
>
> With my alternate solution just described, simply including the normal
> pthread header and casting the pointer when making the call would be
> fully legal.
>
> With the approach we previously discussed, where we have to ensure
> that no TU that accesses the contents of a mutex or cv structure can
> see both the C11 and POSIX versions, The C11 TUs would have to contain
> prototypes for the aliased POSIX functions like:
>
> int __pthread_mutex_lock(mtx_t *);
>
> Note that this is a perfectly correct prototype because mtx_t is just
> this TU's typedef name for the tagless "struct { union { ... } __u; }"
> that it's using, which is "the same type" as pthread_mutex_lock.c's
> pthread_mutex_t.
Actually, unless the C11 functions actually access the mutex object,
their implementation files don't need to avoid having both types
visible. Only the TUs that dereference the object (i.e. the pthread
ones) need to ensure that only one version of the type is visible.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
