mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Jens Gustedt <jens.gustedt@inria.fr>
To: musl@lists.openwall.com
Subject: Re: C threads, v. 6.2
Date: Fri, 29 Aug 2014 09:56:39 +0200	[thread overview]
Message-ID: <1409298999.4476.163.camel@eris.loria.fr> (raw)
In-Reply-To: <20140828233809.GE12888@brightrain.aerifal.cx>

[-- Attachment #1: Type: text/plain, Size: 2519 bytes --]

Am Donnerstag, den 28.08.2014, 19:38 -0400 schrieb Rich Felker:
> Perhaps I should clarify: what I mean by "what we're doing" is
> defining pthread_mutex_t and mtx_t as separate structs with identical
> contents (a single union with no tag). Your latest version with
> __pthread_mutex_t is not a possibility because it changes the C++ ABI.
>
> In principle we could do something like with the definition of
> pthread_t where it changes depending on whether the header is being
> used in a C or C++ program, but that's quite ugly and not something
> I'd much like to do...
> 
> Is your conclusion still that it's okay? I think so but I just want to
> confirm.

Ok, now I see.

(for the discussion let's just take mutexes as example, similar would
apply for cv)

Yes, done carefully this would be an option. By carefully meaning that
we have to ensure that all TU see only either type, not both.

For pthread this would be easy, basically nothing changes, good.

For C threads that base themselves on pthread this would be a pain. We
have to call pthread functions with mutex parameters. We couldn't just
simply include the pthread.h header, since this would drag in the
pthread type definitinions.


We could get away with it, by some hackery

** Option 1:

C threads do something like the following in all C thread TU, or have
an intermediate header "threads_impl.h" that does this

typedef mtx_t pthread_mutex_t
#define __DEFINED_pthread_mutex_t

#include "pthread_impl.h"

** Option 2:

In "pthread_impl.h" have:

typedef pthread_mutex_t __pthread_mutex_t;

In "threads_impl.h" have:

typedef mtx_t __pthread_mutex_t;

and then let all __pthread_xxxxx functions that we provide to be used
by the C thread implementation use __pthread_mutex_t.

***

All of this would explode in our face the day a user wants to use
pthread_mutex_t and mtx_t in the same application. A use case could be
that he uses one library that protects CS with pthread_mutex_t and
another that uses mtx_t. Now suddenly we have code that sees two
different types, with possibly subtle bugs due to aliasing.

So in conclusion, it is doable, but I don't like it at all.

Jens

-- 
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2014-08-29  7:56 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-27 22:11 Jens Gustedt
2014-08-27 23:46 ` Rich Felker
2014-08-28  9:40   ` Jens Gustedt
2014-08-28 11:41     ` Szabolcs Nagy
2014-08-28 16:15     ` Rich Felker
2014-08-28 19:28       ` Jens Gustedt
2014-08-28 20:00         ` Rich Felker
2014-08-28 20:55           ` Szabolcs Nagy
2014-08-28 21:38             ` Jens Gustedt
2014-08-28 21:34           ` Jens Gustedt
2014-08-28 21:56             ` Rich Felker
2014-08-28 23:25               ` Jens Gustedt
2014-08-28 23:38                 ` Rich Felker
2014-08-29  7:56                   ` Jens Gustedt [this message]
2014-08-29  8:02                     ` Jens Gustedt
2014-08-29 15:57                       ` Rich Felker
2014-08-29 19:01                         ` Jens Gustedt
2014-08-30  5:30                           ` Rich Felker
2014-08-30  7:43                             ` Jens Gustedt
2014-08-30  8:54                               ` Jens Gustedt
2014-08-31  0:30                               ` Rich Felker
2014-08-31  1:31                                 ` Rich Felker
2014-08-31  2:44                                   ` Rich Felker
2014-08-31  7:09                                     ` Jens Gustedt
2014-08-29 15:56                     ` Rich Felker
2014-08-29 18:40                       ` Jens Gustedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1409298999.4476.163.camel@eris.loria.fr \
    --to=jens.gustedt@inria.fr \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).