Date: Sat, 17 Dec 2011 00:09:14 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Ed Schouten <ed@80386.nl> Cc: threads@freebsd.org, arch@freebsd.org Subject: Re: [Patch] C1X threading support Message-ID: <20111216220914.GW50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111216214913.GA1771@hoeg.nl> References: <20111216214913.GA1771@hoeg.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
--ubsQ1kiTK0VEt5fK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Dec 16, 2011 at 10:49:13PM +0100, Ed Schouten wrote:
> Hi folks,
>=20
> We can expect C11 (or C12) to be released in the nearby future. I
> already took the liberty of adding fallbacks for some of the language
> keywords to <sys/cdefs.h>, but it seems the standard also includes a new
> threading API.
>=20
> In my opinion the ISO folks suffer a bit from the Not Invented Here
> syndrome. In an earlier revision of the C1X specification, they even
> described a `struct xtime', which had a purpose identical to `struct
> timespec'. The same holds for the threading API. It can be 1:1 mapped to
> a subset of pthread -- why not simply standardize that subset then?
>=20
> Putting my personal objections aside, I do think we should add support
> for the API by the time C1X is final. Attached is a patch that adds the
> new API to libthr. It simply wraps all the calls around pthread. Even
> the objects used by the API are type compatible with the ones used by
> pthread.
>=20
> The questions:
>=20
> - As this API is just a second-class citizen and will not be used by the
> C library, I suspect there is no need for underscore prefixing and
> weak aliasing. Is this correct?
If application that does not use the new interface supposed to be
able to implement function with new names, then the not-underscored
symbols must be weak.
>=20
> - When accompanied with man pages, are there any objections if I commit
> this to SVN when C1X is official?
+int
+cnd_init(cnd_t *cond)
+{
+
+ if (_pthread_cond_init(cond, NULL) !=3D 0)
+ return (errno =3D=3D ENOMEM ? thrd_nomem : thrd_error);
+ return (thrd_success);
+}
pthread_cond_init does not set errno, it returns error.
There are several more instances of such errno use in the patch.
Do you have reference to the draft ?
--ubsQ1kiTK0VEt5fK
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iEYEARECAAYFAk7rwYoACgkQC3+MBN1Mb4gs5wCgzHFzXHOpcpSYL8VL9n9Zm2nz
V7oAnjAWXKFwKlFwG6T3hXn6TF6qTMBh
=llEm
-----END PGP SIGNATURE-----
--ubsQ1kiTK0VEt5fK--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111216220914.GW50300>