|Alexander Nedotsukov||Nov 18, 2004 11:54 pm|
|Daniel Eischen||Nov 19, 2004 8:01 am|
|Joe Marcus Clarke||Nov 19, 2004 9:52 am|
|Daniel Eischen||Nov 19, 2004 10:09 am|
|Joe Marcus Clarke||Nov 19, 2004 10:16 am|
|Daniel Eischen||Nov 19, 2004 11:53 am|
|mez...@cox.net||Nov 19, 2004 1:21 pm|
|Joe Marcus Clarke||Nov 19, 2004 2:07 pm|
|Niall Douglas||Nov 20, 2004 2:10 am|
|Alexander Nedotsukov||Nov 22, 2004 5:48 am|
|Daniel Eischen||Nov 22, 2004 6:14 am|
|Joe Marcus Clarke||Nov 22, 2004 6:28 am|
|Alexander Nedotsukov||Nov 22, 2004 8:30 am|
|Craig Rodrigues||Nov 26, 2004 10:56 am|
|Alexander Nedotsukov||Nov 29, 2004 12:11 am|
|Subject:||Question about our default pthread stack size|
|From:||Joe Marcus Clarke (mar...@marcuscom.com)|
|Date:||Nov 22, 2004 6:28:20 am|
On Mon, 2004-11-22 at 01:15 -0500, 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. 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.
Okay, but I still don't see the reason for not increasing the stack size now to be more inline with Solaris and Linux. We seem to be adopting other Solaris-like threading attributes (based on some of your previous emails), and this would help other popular software packages "just work" on FreeBSD.
I've searched the GTK archives and can see that the stack size was removed from the thread pool api, but not from creating other threads. The reason for removing it seems silly, but such is life...
Right. You can still create individual threads, and specify a per-thread stack size. However, this cannot be done with GThreadPools.
-- PGP Key : http://www.marcuscom.com/pgp.asc