Bug #9884
closedthread_pthread.c assumes pthread_t is a scalar type
Description
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.
Files
Updated by ReiOdaira (Rei Odaira) almost 10 years ago
- 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.
Updated by ko1 (Koichi Sasada) almost 10 years ago
(2014/05/31 7:28), Rei.Odaira@gmail.com 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
Updated by nobu (Nobuyoshi Nakada) almost 10 years ago
- 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.
Updated by kosaki (Motohiro KOSAKI) almost 10 years ago
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.
Updated by ReiOdaira (Rei Odaira) almost 10 years ago
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.
Updated by kosaki (Motohiro KOSAKI) almost 10 years ago
On Wed, Jun 11, 2014 at 9:33 PM, Rei.Odaira@gmail.com 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.htmlIEEE 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.