On Fri, Apr 17, 2015 at 08:10:40PM +0200, Jan Kiszka wrote:
> On 2015-04-17 20:08, Gilles Chanteperdrix wrote:
> > On Fri, Apr 17, 2015 at 08:05:57PM +0200, Jan Kiszka wrote:
> >> On 2015-04-17 19:50, Gilles Chanteperdrix wrote:
> >>> On Fri, Apr 17, 2015 at 07:34:30PM +0200, Jan Kiszka wrote:
> >>>> Hi,
> >>>>
> >>>> analyzing page faults of an application that prefers to set its own
> >>>> stacks, I noticed a problem in Xenomai (2 and 3), at least from the
> >>>> usability POV: We document the minimum stack stack as PTHREAD_STACK_MIN
> >>>> + 1 page, at least in Xenomai 3, and we enforce that on thread creation.
> >>>> However, enforcement is doomed to fail if the stack is preallocated (and
> >>>> that too small).
> >>>>
> >>>> As we cannot detect if the user set a stack address in pthread_attr_t, I
> >>>> would suggest to fail thread creation instead of performing it with
> >>>> improper parameters. Other suggestions? If not, I would prepare a patch
> >>>> for Xenomai 3 (for 2 only if desired).
> >>>
> >>> It seems to me we can detect the parameters in the pthread_attr_t
> >>> using pthread_attr_getstack. So, we can get __wrap_pthread_create to
> >>> fail if the size is not sufficient.
> >>
> >> Nope, unfortunately not:
> >>
> >> "If the pthread_attr_getstack() function is called before the stackaddr
> >> attribute has been set, the behavior is unspecified."
> >
> > It is unspecified by POSIX, but Xenomai supports only two
> > implementations, glibc and uClibc, so, we can look at what these two
> > libraries do. I would bet they return you a NULL stack pointer or
> > something.
>
> I would have expected that, too, but the results for glibc seem random.
> Plus there is the risk that something changes, thus we become
> version-dependent.
Ok then, what about the influence of pthread_attr_setstack() on
pthread_attr_getstacksize(), maybe more luck there?
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
