[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [microblaze-uclinux] pthread_attr_setstack() limitation
This is why I asked about the default value for the stack size--it could
have come from this define and really caused problems. While the user has
total control using pthread_attr_setstack(), I agree that it is probably
useful to protect against passing in zero. Something non-zero but token,
perhaps 8, with a comment in the kernel source code explaining the
situation probabaly makes sense.
Paul
Quoting Brettschneider Falk <fbrettschneider@xxxxxxxxxxxxxxxxx>:
> Hi,
> OK, 0x0 may be a bit all-out. But what is a useful limitation? Here, I
> saw
> about 1KB as peak value.
> I think if one uses that special function, he knows what he's doing. Any
> limitation might be wrong. And whatever I set on stack creation, I always
> can write beyond the stack range.
> For myself, I measured the stack usage with a test pattern and tweaked it
> afterwards.
> unsigned int* pCurStackAddr;
> ...
> while (pCheckStackAddr != pCurStackAddr) {
> if (*pCheckStackAddr != 0x5354414B) { // 'STAK'
> pLastUsedStackAddr = pCheckStackAddr; break;
> }
> pCheckStackAddr++;
> }
> E.g. I shared the SRAM memory for several threads with different fixed
> stack
> sizes, and the sizes were quite small, but stable, so I can predict its
> max
> value.
>
> CU, F@lk
>
> > -----Original Message-----
> > From: owner-microblaze-uclinux@xxxxxxxxxxxxxx
> > [mailto:owner-microblaze-uclinux@xxxxxxxxxxxxxx]On Behalf Of John
> > Williams
> > Sent: Monday, February 27, 2006 11:18 PM
> > To: microblaze-uclinux@xxxxxxxxxxxxxx
> > Subject: Re: [microblaze-uclinux] pthread_attr_setstack() limitation
> >
> >
> > Hi Falk,
> >
> > Brettschneider Falk wrote:
> >
> > > as I was playing around to use an 8KB SRAM as stack via
> > > pthread_attr_setstack() I saw there's a strange stacksize
> > limitation in the
> > > pthread lib. I removed that locally, because a global
> > search doesn't show a
> > > explanation that makes sense to me. Could it be changed in
> > the official CVS
> > > tree as well? See the patch below.
> >
> > I might be missing something here, but allowing zero sized
> > stacks sounds
> > like a recipe for disaster, particularly on a noMMU system. The first
> > function call or local variable allocation made by a thread will start
> > trashing memory. Whether the limit should be 16kb, or 8kb, or 4, or
> > whatever, is debatable, but zero seems like a bad idea?
> >
> > Custom stacks setup via pthread_attr_setstack () can be any size you
> > like - the library is assuming you know what you are doing in
> > that case.
> >
> > John
> >
>
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/