<div dir="ltr">On 13 April 2013 00:56, Dmitry Olshansky <span dir="ltr"><<a href="mailto:dmitry.olsh@gmail.com" target="_blank">dmitry.olsh@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">12-Apr-2013 18:40, Manu пишет:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br></blockquote><div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
It measures in the megabytes on PC's, I'm used to working on machines<br>
with ~32k stack, I use it aggressively, and I don't tend to run out.<br>
</blockquote>
<br></div>
Just a moment ago you were arguing for some quite different platform :)<br></blockquote><div><br></div><div style>Hey? I think 32k is pretty small, and I find it comfortable enough. I'm just saying that most people who are only concerned with PC have nothing to worry about.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Regardless - think fibers on say servers. These get no more then around 64K of stack. In fact, current D fibers have something like 16K or 32K.<br>
There even was report that writeln triggered stack overflow with these, so the size was extended a bit.<br></blockquote><div><br></div><div style>If it was overflowing 64k, then the function that allocates 1k for some string processing is not taking the significant share.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
In general simple non-GUI threads on Windows get 64K by default (IRC).<br></blockquote><div><br></div><div style>And that's heaps.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
In the end if one library thinks it's fine to burn say 32K of stack<br>
with alloca but then it calls into another one that burns another<br>
chunk with alloca and so on untill happily stack overflowing<br>
(sometimes, on some systems at the right time!). Call graphs to<br>
calculate this is only available for the final app.<br>
<br>
Maybe just adding a separate thread-local growable stack for data<br>
would work - at least it wouldn't depend on sheer luck and<br>
particular OS settings.<br>
<br>
<br></div><div class="im">
If you're saying the stack is a limited resource, therefore it's unsafe<br>
to use it, then you might as well argue that calling any function is an<br>
unsafe process.<br>
</div></blockquote>
<br>
s/limited/unpredictably limited/<br>
<br>
"calling any function is an unsafe process" - indeed in principle you don't know how much of stack these use unless you measure them or analyze otherwise.<br>
<br>
It's awful that on 32 bit system you can't expect stack to be arbitrarily long (as much as you'd use of it) due to threads quickly using up all of virtual memory. On 64-bit something to that effect is achievable</blockquote>
<div><br></div><div style>Just apply some common sense to your stack usage. Don't allocate hundreds of kb (or even 10s of kb) at a time.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Some common sense is required.<br>
</blockquote>
<br></div>
Exactly except that in the library there is no knowledge to get a measure of "common sense". It can't tell how somebody intends to use it, especially the standard library.</blockquote><div><br></div><div style>
If the function can not be called recursively, then you can assume a reasonable amount of memory. If it can, or it does by design, then consider the design of the function more carefully, maybe there's other solutions.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
> I wouldn't personally burn more than 1k<br>
> in a single function, unless I knew it was close to a leaf by design<br>
> (which many library calls are).<br>
<br></div>
And you trust that nobody will build a ton of wrappers on top of your function (even close to leaf one)? Come on, "they" all do it.</blockquote><div><br></div><div style>A ton of wrappers in phobos? If it's their own program and they write code like that, they're probably using the heap.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
90% of what we're dealing with here are strings, and they tend to<br>
measure in the 10s of bytes.<br>
</blockquote></div>
???<br>
Not at all, paths could easily get longer the 256, much to legacy apps chagrin.</blockquote><div><br></div><div style>And they fall back to the heap. No problem.</div><div style>If I care about avoiding heap usage, I can know to avoid such deep paths. Ie, it can be controlled by the user.</div>
</div></div></div>