[M3devel] FW: variations of waitpid..?

[Jay]

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'tknow 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 compileror 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 usageand using heap instead. However there are large tradeoffs inperf and medium tradeoffs in debuggability (debuggers do a betterjob of immediately showing the contents of character arrays, insteadof 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 addressspaceexhaustion.
True, even heap and addresspace can run out, by either being "only" 32bits, orvia 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 compactionseems 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/20090102/0fe074c3/attachment-0002.html>