On 2/23/07, Roland McGrath [EMAIL PROTECTED] wrote:
Unfortunatly, due to alignment the NPTL pthread_cond_t grows larger
than the Linuxthreads version when I add the padding. This is the only
structure the grows larger in size than before. Is there any way I can
avoid adding the padding?
It
I did a couple of tests and I verified that I have no words to spare.
Adding an extra int __pad forces the structure to grow by 8 bytes
due to the long long alignment requirements.
Just reorder the fields so that the 32-bit fields are all in groups of 2 or 4.
All that should matter is that the
In the new structure we have shifted everything up because __lock is
now an integer, instead of a _pthread_fastlock with a 4 word lock
structure. Should I add padding after __lock e.g. int pad[3]?
Yes, you must dedicate those words to compatibility only.
In an old executable the following
On 2/23/07, Roland McGrath [EMAIL PROTECTED] wrote:
In the new structure we have shifted everything up because __lock is
now an integer, instead of a _pthread_fastlock with a 4 word lock
structure. Should I add padding after __lock e.g. int pad[3]?
Yes, you must dedicate those words to
Unfortunatly, due to alignment the NPTL pthread_cond_t grows larger
than the Linuxthreads version when I add the padding. This is the only
structure the grows larger in size than before. Is there any way I can
avoid adding the padding?
It looks to me like you have one word to spare. That's
On 2/22/07, Roland McGrath [EMAIL PROTECTED] wrote:
All statically initialized locks are broken. We made locks smaller,
and changed the value of the static initialization.
Smaller? Smaller is easy. And you didn't actually reduce
__SIZEOF_PTHREAD_MUTEX_T, did you? This seems like it would
On Monday 19 February 2007, Jeff Bailey wrote:
On 19/02/07, Aurelien Jarno [EMAIL PROTECTED] wrote:
if the breakage is just in pthreads, i dont think the libc ABI needs to
be
bumped, just the pthread one ? libc provides look ahead stub functions
for
pthreads, so it shouldnt be
7 matches
Mail list logo
