[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: bug or feature?



The spec seems a little vague about stackaddr and doesn't say exactly what it means. I think for compatibility NPTL should do what LinuxThreads does. Comments?

How important is compatibility of an obsolescent/deprecated API? Given NPTL's goal of binary compatiblity with LinuxThreads, this is a bit tricky...


On one side, the SUSv3 pthread_attr_setstacksize() spec indicates that the stackaddr param points to "storage":

The stackaddr attribute specifies the location of storage to be used for the created thread's stack. The size of the storage shall be at least {PTHREAD_STACK_MIN}.

My interpretation of "storage" is that it starts at a low address and grows up, like a malloc()'ed region. It doesn't say anything about the relationship of the stackaddr param to the initial stack pointer in the thread...


I'd think it would be reasonable for a client of the API to expect the behavior to be the same as pthread_attr_setstack():

The stack attributes specify the area of storage to be used for the created thread's stack. The base (lowest addressable byte) of the storage shall be stackaddr, and the size of the storage shall be stacksize bytes.

But, when an API is ambiguous and you have a goal of binary compatibility, it seems clear what the decision should be -- remain compatible, and encourage folks to use pthread_attr_setstack() (supported by the link time warning...)


matt.





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]