Jan Kiszka wrote:
> Hi,
> 
> something for the night: Can someone explain why normal pthreads can be
> restricted to initially use only the stack size provided via
> pthread_attr_setstacksize() while any rt-mapped thread (posix and
> native) refuse to accept this? For a simple test, compile the attached
> program one time as normal
> 
>     gcc -lpthread -o stacksize stacksize.c
> 
> and the other time against xeno's posix skin
> 
>     gcc `xeno-config --posix-cflags` `xeno-config --posix-ldflags` \
>         -o stacksize.o stacksize.c
> 
> Then compare the memory requirements of both processes - they should
> differ by 2M, the stack size when pthread_attr_setstacksize is not used.
> Strange - and also critical when considering larger applications...

This has been nailed down now to be some strange linker problem: while
the standard version of the stacksize demo calls the latest
pthread_create (__pthread_create_2_1 in glibc-2.3.x), the wrapped
real-time version and likely also applications linked against libnative
call an older pthread_create (__pthread_create_2_0). That variant
assumes that pthread_attr_t does not yet contain things like the stack
size and fills in the standard value again. :(

Can anyone with another build environment than my SuSE 10 confirm this?

> 
> So far I only tested against 2.1, but I don't see a reason why 2.0.x
> should behave different. Will get checked, though.
> 

Same behaviour on 2.0.x (SVN).

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to