<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
The pthreads code appears to leak for every thread created, as a result of trying to set stack size.<BR>I'll just fix it, once confirmed.<BR>
<BR>Setting stack size is basically impossible all around.<BR>Both by the user and by "the OS".<BR>
<BR>By the user:<BR>
<BR>If the user calls into any dynamically linked code he didn't write, he doesn't<BR>know what is needed, without a lot of testing, and it can change in time.<BR>
<BR>If the user so much as compiles with different flags or a different compiler<BR>or targeting a different platform, stack use will change.<BR>
<BR>By the OS:<BR>
<BR>Same thing -- the OS doesn't know how much stack any user will need.<BR>
<BR>
<BR>Personally I generally practise and recommend minimizing stack usage<BR>and using heap instead. However there are large tradeoffs in<BR>perf and medium tradeoffs in debuggability (debuggers do a better<BR>job of immediately showing the contents of character arrays, instead<BR>of pointers, which they don't follow automatically, at least cdb/ntsd/windbg,<BR>not sure about the various gdb/dbx/visualstudio).<BR>
<BR>
<BR>A terrible pattern imho, is stuff like<BR> char FilePath[some large maximum like 200 or 1000];<BR>
<BR>They use up the stack fast, are usually wasteful over-allocations, and sometimes<BR> arbitrary capacity-limiting under-allocations. For paths in particular,<BR> Win32 advertises two maximums, one of which is wrong, the other of which is<BR> suspicous -- 260 and 32K. 32K isn't clearly correct due to the availability of<BR> relative opens.<BR> Even if 32K is considered correct, it is way too much to allocate "just in case".<BR> Better to determine the actual needed size and allocate that.<BR> (I think current Cygwin code does just this though -- blow up a bunch of buffers to 32K.)<BR> Imho.<BR>
<BR>Oh, and the common Unix advertisement of 1024 is also perhaps wrong.<BR>You know, what happens if I am using SMB to NT, or to another system with a different max?<BR>Do paths beyond 1024 get truncated, or unavailable, or overflow buffers?<BR>They can certainly exist.<BR>I'll have to try it out sometime.<BR>
<BR>In general on disk structures are all "relative" and have no limits for full paths,<BR>only usually for individual path elements.<BR>
<BR>The stack is generally of relatively small capacity, and when it is exhausted,<BR>that is more difficult to detect and recover from, than heap or addressspace<BR>exhaustion.<BR>
<BR>True, even heap and addresspace can run out, by either being "only" 32bits, or<BR>via fragmentation, and are difficult to recover from.<BR>I personally don't defend against fragmentation, and it worries me some.<BR>It's maybe not a concern in Modula-3 due to compaction, however compaction<BR>seems also bad in that it requires larger contiguous memory.<BR>Fragmentation is good. Fragmentation is bad..<BR>
<BR> - Jay<BR><BR><BR><BR><BR>> Date: Fri, 2 Jan 2009 11:32:57 +0100<BR>> From: wagner@<BR>> To: m3devel@<BR>> Subject: Re: [M3devel] FW: variations of waitpid..?<BR>> <BR>> Quoting Jay:<BR>> <BR>> > (Personally I have seen precious little code that cares about stack <BR>> > size, just seems to somehow get along, combined with the fact that <BR>> > the current Modula-3 pthread code very likely leaks on some <BR>> > platforms attempting to deal with stack size, makes me inclined to <BR>> > just rip out the code..but yeah..just fix the leak...)<BR>> <BR>> Please don't do that (remove the ability to set stack sizes). I know<BR>> that for most of the programs I wrote years ago we had to adapt stack<BR>> sizes for threads carefully. That was with user threads though.<BR>> <BR>> Olaf<BR><BR></body>
</html>