[M3devel] FW: variations of waitpid..?

[Tony Hosking]

What OS is this leak on?  I don't think it is anything in the Modula-3  
wrappers to pthreads, but please confirm.

On 3 Jan 2009, at 05:36, Jay wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090103/e847a9db/attachment-0002.html>