public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Danny Smith" <danny_r_smith_2001@yahoo.co.nz>
To: Pascal Obry <obry@ACT-Europe.FR>, binutils@sources.redhat.com
Subject: Re: binutils, why default stack size this low ?
Date: Wed, 16 Jan 2002 20:32:00 -0000	[thread overview]
Message-ID: <20020117035529.2169.qmail@web14504.mail.yahoo.com> (raw)
In-Reply-To: <20020116213233.818F22264C@paris.ACT-Europe.FR>

 --- Pascal Obry <obry@ACT-Europe.FR> wrote: > 
> > Larger reserves limited the number of threads you could start.  The
> > MSVC compiler had a much smaller reserve than Cygwin before the patch.
> 
> Right, but this has the bad consequence to break some non-threaded
> programs. It was always possible to change the default stack size on the
> command line. 

It still is.

Of course this is also true for non-threaded programs, but
> I
> think that most of the programs around us do not use threads.
> 
> Even on the Ada world, where tasking is part of the language, we have
> many
> programs that do not use tasks (threads), and those who do does not have
> enough tasks to break the limit (which is around 35 if my memory 
> is right).
> 
> Pascal Obry. 

Well, what should the default be? I chose 2 MB because:

1) Default of native compiler is 1 MB. Inspection of apps built by other
W32 comilers indicates they have similar or smaller default stack reserve. 
1 MB, however, is not sufficient to bootstrap GCC. 2 MB is.

2) Threads (and fibers).  Although CreateThread allows user to set stack
size, if size is smaller than default, the new thread uses the same size as
the calling thread.  With fibers, it is not possible to specify stack
reserve; the size of the calling thread is always used. Apps that use
fibers ("lightweight threads") can often (try to) create a 100 or more.


The larger the stack reserve, the more likely that illegitimate 
__stdcall/__cdecl fixups will go undetected.  One way that this can happen
is to compile C code with -mrtd.  Library functions that are not marked as
__cdecl in headers will also be treated as stdcall.  Sooner or later the
stack will overflow. Better sooner than later.

Danny

http://my.yahoo.com.au - My Yahoo!
- It's My Yahoo! Get your own!

  reply	other threads:[~2002-01-17  3:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-16 14:08 Pascal Obry
2002-01-16 20:32 ` Danny Smith [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-01-16 13:32 Pascal Obry
2002-01-16 14:03 ` DJ Delorie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020117035529.2169.qmail@web14504.mail.yahoo.com \
    --to=danny_r_smith_2001@yahoo.co.nz \
    --cc=binutils@sources.redhat.com \
    --cc=obry@ACT-Europe.FR \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).