pthread portability
The below diff fixes one problem: you can't compare pthread_t values
directly. Only the function pthread_equal(3) is defined. Direct
comparison usually works because most implementations define pthread_t
as an integer type.
Relatedly, INVALID_THREAD is defined as (pthread_t)0. I don't think this
is a portable way of checking whether a thread is valid, and I don't
know if it's actually possible to get an "invalid" thread out of
pthread_create(3) if it succeeds (returns 0). In the cases where you're
setting a pthread_t to INVALID_THREAD, maybe using a struct that
includes a pthread_t and a 'valid' bool would be preferable.
Thanks for your time,
Michael
diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index 4196b0e..f2e5aed 100644
--- a/src/bin/pgbench/pgbench.c
+++ b/src/bin/pgbench/pgbench.c
@@ -3791,7 +3791,7 @@ main(int argc, char **argv)
{
int err = pthread_create(&thread->thread, NULL, threadRun, thread);- if (err != 0 || thread->thread == INVALID_THREAD)
+ if (err != 0 || pthread_equal(thread->thread, INVALID_THREAD))
{
fprintf(stderr, "could not create thread: %s\n", strerror(err));
exit(1);
@@ -3819,7 +3819,7 @@ main(int argc, char **argv)
TState *thread = &threads[i]; #ifdef ENABLE_THREAD_SAFETY
- if (threads[i].thread == INVALID_THREAD)
+ if (pthread_equal(threads[i].thread, INVALID_THREAD))
/* actually run this thread directly in the main thread */
(void) threadRun(thread);
else--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Michael McConville wrote:
The below diff fixes one problem: you can't compare pthread_t values
directly. Only the function pthread_equal(3) is defined. Direct
comparison usually works because most implementations define pthread_t
as an integer type.
So is there a platform where this assumption doesn't hold?
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alvaro Herrera wrote:
Michael McConville wrote:
The below diff fixes one problem: you can't compare pthread_t values
directly. Only the function pthread_equal(3) is defined. Direct
comparison usually works because most implementations define
pthread_t as an integer type.So is there a platform where this assumption doesn't hold?
Not sure.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
## Alvaro Herrera (alvherre@2ndquadrant.com):
The below diff fixes one problem: you can't compare pthread_t values
directly. Only the function pthread_equal(3) is defined. Direct
comparison usually works because most implementations define pthread_t
as an integer type.So is there a platform where this assumption doesn't hold?
E.g. FreeBSD has "typedef struct pthread *pthread_t;" with a
non-trivial "struct pthread".
Regards,
Christoph
--
Spare Space
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Christoph Moench-Tegeder <cmt@burggraben.net> writes:
## Alvaro Herrera (alvherre@2ndquadrant.com):
The below diff fixes one problem: you can't compare pthread_t values
directly. Only the function pthread_equal(3) is defined. Direct
comparison usually works because most implementations define pthread_t
as an integer type.
So is there a platform where this assumption doesn't hold?
E.g. FreeBSD has "typedef struct pthread *pthread_t;" with a
non-trivial "struct pthread".
Seems like pointer comparison would be sufficient in that case, so
I'm still not following what real-world problem this change fixes.
I read the POSIX spec's rationale for pthread_equal and found it
utterly unconvincing, BTW. If pthread_equal tries to dereference
the given pointer and said pointer is stale, what is the reason
to think it even points to still-allocated memory?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers