Bug #9884: thread_pthread.c assumes pthread_t is a scalar type

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: ruby 2.2.0dev (2014-05-30 trunk 46238) [x86_64-linux]
• Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN

[ReiOdaira (Rei Odaira)]

Many code lines in thread_pthread.c assume pthread_t is a scalar type. For example,

    thread_debug("ubf_select_each (%p)\n", (void *)th->thread_id);

and

    if (!timer_thread_id) {

I don't think the standard guarantees pthread_t is a scalar type. z/OS defines pthread_t as a struct, and there seem to be other such environments.
https://sourceware.org/pthreads-win32/faq.html

I understand it could be too cumbersome to rewrite the source, assuming pthread_t might not be a scalar, and actually I am not sure what would be the best way to rewrite it, but I appreciate it if you guys could think of it for the maximum portability. If needed, I am willing to list the source lines to be rewritten.

[ReiOdaira (Rei Odaira)]

• File opaque_thread_id.patch opaque_thread_id.patch added

How about this patch? I tested this on x86/Linux with -DTHREAD_DEBUG=-1. No error happened in make test or test-all.

[ko1 (Koichi Sasada)]

(2014/05/31 7:28), [e-mail] wrote:

How about this patch? I tested this on x86/Linux with -DTHREAD_DEBUG=-1. No error happened in make test or test-all.

i have no objection.

--
// SASADA Koichi at atdot dot net

[nobu (Nobuyoshi Nakada)]

• Status changed from Open to Closed
• % Done changed from 0 to 100

Applied in changeset r46406.

---

thread.c: fix for non-scalar pthread_t

• configure.in (rb_cv_scalar_pthread_t): pthread_t is not required
  to be a scalar type.
• thread.c (fill_thread_id_string, thread_id_str): dump pthread_t
  in hexadecimal form if it is not a scalar type, assume it can be
  represented in a pointer form otherwise. based on the patch by
  Rei Odaira at [ruby-core:62867]. [ruby-core:62857] [Bug #9884]
• thread_pthread.c (Init_native_thread, thread_start_func_1),
  (native_thread_create): set thread_id_str if needed.
• vm_core.h (rb_thread_t): add thread_id_string if needed.

[kosaki (Motohiro KOSAKI)]

Just curious. Where is the phrase that describes pthread_t is opaque?

I skimmed current SUS.

sys/types.h contain pthread_t definition.

http://pubs.opengroup.org/onlinepubs/7908799/xsh/systypes.h.html

with following explanation.

"All of the types are defined as arithmetic types of an appropriate length, with the following exceptions: key_t, pthread_attr_t, pthread_cond_t, pthread_condattr_t, pthread_key_t, pthread_mutex_t, pthread_mutexattr_t, pthread_once_t, pthread_rwlock_t and pthread_rwlockattr_t. "

The exception list doesn't include pthread_t. So, I doubt current SUS agree your opinion.

[ReiOdaira (Rei Odaira)]

I was looking at this page:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html

IEEE Std 1003.1-2001/Cor 2-2004, item XBD/TC2/D6/26 is applied, adding pthread_t to the list of types that are not required to be arithmetic types, thus allowing pthread_t to be defined as a structure.

[kosaki (Motohiro KOSAKI)]

On Wed, Jun 11, 2014 at 9:33 PM, [e-mail] wrote:

Issue #9884 has been updated by Rei Odaira.

I was looking at this page:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html

IEEE Std 1003.1-2001/Cor 2-2004, item XBD/TC2/D6/26 is applied, adding pthread_t to the list of types that are not required to be arithmetic types, thus allowing pthread_t to be defined as a structure.

Ah, OK. Got it. Thanks.