Обсуждение: 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,
"couldnot 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
mainthread */            (void) threadRun(thread);        else
 

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

## 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

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

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.