Why does uv_thread_self() assume pthread_t =~ unsigned long?

[Iñaki Baz Castillo]

Hi, in uv-common.c:


unsigned long uv_thread_self(void) {
#ifdef _WIN32
return (unsigned long) GetCurrentThreadId();
#else
return (unsigned long) pthread_self();
#endif
}


According to pthread_self() the returned value has type pthread_t
which is not specified:

http://man7.org/linux/man-pages/man3/pthread_self.3.html

POSIX.1 allows an implementation wide freedom in choosing the type
used to represent a thread ID; for example, representation using
either an arithmetic type or a structure is permitted. Therefore,
variables of type pthread_t can't portably be compared using the C
equality operator (==); use pthread_equal(3) instead.

Thread identifiers should be considered opaque: any attempt to use a
thread ID other than in pthreads calls is nonportable and can lead to
unspecified results.

Thread IDs are guaranteed to be unique only within a process. A
thread ID may be reused after a terminated thread has been joined, or
a detached thread has terminated.

The thread ID returned by pthread_self() is not the same thing as the
kernel thread ID returned by a call to gettid(2).


So how safe (or portable) is the (unsigned long) pthread_self() line
above? If for example the implementation decides to use a struct for
the pthread_t type, the above cast would fail to compile.


Regards.


--
Iñaki Baz Castillo
<i...@aliax.net>

[Saúl Ibarra Corretgé]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Not sure why it's implemented like this, so I cannot comment on that.

We could have a uv_thread_id_t opaque struct (union really) which
stored both Windows and Unix representations, and have a
uv_thread_compare function that does the equivalent of pthread_compare.

Can you open an issue on GH? Also, patches are always welcome :-)

- --
Saúl Ibarra Corretgé
bettercallsaghul.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBAgAGBQJTO+qpAAoJEEEOVVOum8BZLecP/2VRtcaNaJwfix/ykk2FFQgU
+9bsWZBA67cygMtGMwlp83vALU4WtIDced/Vq/3RGIe6S8qfETZmFF4nFdgSME9c
id49AIbHsJ9AqnchL0uCII+pYRnnH8uf0V9fIC4mC46i8SCBXcjhuoEn/keicufF
csWbwB+aM5l8JL28wap4JVcerqw9e+mR1bHp4lWl7CHp7XB/Un3tTrgKgt3XXfaJ
2l07dmVrLGs9KmTsBOvi+zaHqt4MDTPcXQUz1vmyThsgrMs67dAA+s+CRJFRKoTv
kEw5i4jvIw0vuKH72tkF/ftCciSKZkm2FWtBZ2GzeMc5WwdU6DAp78aMhhq2TJfk
AF13sAUj1XRoLYhj5ZrHNBfN1ciuKVUd1DusJN+OdFP+ddK/NYFMkemfY71ZftU0
jLO3z+GgOl5tSy9yZnxjdEGZFVYoqIE9nqnNEsCye0HTatP3ZKgnLgB3LMuO34Mj
Oo7+prYiADKapMkB7SD4jxQXaVE7NqVNfo1VClfjrZRcBGefPiDe7wFGMev21gS4
hd3yZtyyXmNlb7k8XqqD7mAjQkAqVNXGBmySy9L7HPi2miw96Ge1Ly5N474E8AJQ
wcU3vCJiuHQ6RL4v7UJ8kgyfCapmPgID54bpw6RcIz4o1Y+lfApFj2397s57E/Xg
Lgcdm0ZGMRSsHuN/5St3
=pDRR
-----END PGP SIGNATURE-----

[Iñaki Baz Castillo]

2014-04-02 12:47 GMT+02:00 Saúl Ibarra Corretgé <sag...@gmail.com>:
> We could have a uv_thread_id_t opaque struct (union really) which
> stored both Windows and Unix representations, and have a
> uv_thread_compare function that does the equivalent of pthread_compare.

Ohh, the answer I was looking for was "every *nix and BSD flavors
return an unsigned long, so this is the way to go".

In fact I rely on that in my code as I store the returned value of
uv_thread_self in a map whose keys are unsigned longs.

[Saúl Ibarra Corretgé]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

That might have been the reason, but I don't know it.

- --
Saúl Ibarra Corretgé
bettercallsaghul.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBAgAGBQJTO+5eAAoJEEEOVVOum8BZ9QQQAKkY0NpWQArrpF3HklLcztFG
OdRGV61qY/h3/ODI5881LXYMzlLT0EWoufxcigSDa/fnB9/8PLqlmDHycJGRKmJE
Ct+DNzccnEr2m3fQFn8qfVANMVMqKocCNvENd0bydTdMkfTBJe72ehn08DjG0DMG
jpdspZMI+C5l3bjEvJ8hGptpzCRPxQHZGTHBxdS1OQrekcx9kt7+9EFQ/E/yyf94
OIlDohd7BMbGy+ima1gM5WHGGg6hfzrmHFRq25HzFhho9VswsSW01aZKSzda1ISn
xM/+boU6Ht2L17zE957/L7O7AouVbagNb+udaKzPIyDYGHDv9JVq13hvkm5xn+nT
25jbPFInwRTN22lCx7f2cmIhoXOeuSlKRjrQou97OQsyJDefGzjFaPCl6yw20luP
cVBJxVA0y3ES1B1hFcCj5C3XbUYfYLcsauBl4fGo6gRO2Dr908+KOyxpkF62I+Ht
nDDh7vHKWUXCQZI2B3tRRoQAzqrQLCB/nW0qsIHoMvChtWjkvDwmqPV4cH02CIEp
i7mxalfmzz4dzy8IdbVyBqZxbf0MFWKm4MvW0xh7PXef4FK3fhdp1g38SxK1QBPt
SMQJxwO8xTX2J80LsIha0vnN70C0sNWrqHsRKrQnoHNaYEh0r7ON0XRRecF7d+Mv
7Byk8yvZWSgyrPc4rU9D
=YVbo
-----END PGP SIGNATURE-----