Date: Mon, 22 Nov 2004 17:30:29 +0900 From: Alexander Nedotsukov <bland@FreeBSD.org> To: Daniel Eischen <deischen@FreeBSD.org> Cc: freebsd-threads@FreeBSD.org Subject: Re: Question about our default pthread stack size Message-ID: <41A1A3A5.20601@FreeBSD.org> In-Reply-To: <Pine.GSO.4.43.0411220058300.29589-100000@sea.ntplx.net> References: <Pine.GSO.4.43.0411220058300.29589-100000@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: >On Mon, 22 Nov 2004, Alexander Nedotsukov wrote: > > > >>Daniel Eischen wrote: >> >> Heavy stack usage is not so evil like it may look like. That "pig" >>will have to allocate big memory chunk anyway and the usual options here >>are to grab phys memory page on the heap through the malloc() or do it >>on the stack. In both of the cases this memory will not be immediately >>allocated. But malloc() way will be slower and this is why multimedia >>processing code may prefer on stack allocation. Another malloc/free() >>disadvantage for C program is potential memory leakage. People may feel >>safer when they don't have to check all return paths but get automatic >>memory disposal. >>One more thing about "Do they know their own stack space requirements". >>No they don't. And the whole idea here I believe was to let them don't >>care at all. I doubt very much if such research for something like >>OpenOffice will worth the efforts. So it is more practical to follow >>Bill's like "no one can beat xxx barrier". Where xxx is 1MB in our 32bit >>case :-) >> >> > >You're missing my point. There is a perfectly good POSIX standard for >setting thread stack size -- you don't even need to allocate it yourself. >Using pthread_attr_setstacksize() is more portable than relying on >the OS to guess at what an application's stack size requirements are. > > Daniel, this is what I said in my very first letter under the topic. I know how portable code must look like. API is good and complete. Let's clear thing up yet more to understand each other completely. My points are: - there is an omision in standard (or better to say something that is hard to standardize) Therefore there is a term like default stack size which can be understood as the amount enough for regular code. Otherwise it will be more logical to make thread stack size argument mandatory for pthread_create(). - main stream follows the stack usage rules I described above and chosen 1MB/2MB for their default stacks size. - we have limit which most likely triggers SIGSEGV. At this point I believe we both agreed that there is a sence to break 64K limit. Right? Than the only open question how much we will grow it up. My point is that if we going to use lower numbers we must give a good reason for that. Some technical issues I guess like performance penalty whatever... My main question I'd like to hear the answer is: If we can not prove being as safe as main stream and do not win anything in technical aspect than why we must do extra work? I can understand if there is some true technical issue which prevents us form be inline with others. But I do not if we just pushing people to use APIs speculating on standard omisions. >We may increase it to 1MB now, but what happens when that is not enough? >And you _know_ one day, perhaps sooner than you realize, that it won't >be enough. > > This will be a problem for everyone not just for FreeBSD users. Perhaps that day will be a good time to prove Solaris/Linux/Windows OS engineers who was right. But now I think we lost the race. All the best, Alexander.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41A1A3A5.20601>