stack size vs. thread stack size
Alexander Terekhov
"Hillel Y. Sims" wrote:
>
> "David Butenhof" <David.B...@compaq.com> wrote in message
> news:EKME8.14$ns3.3...@cacnews.cac.cpqcorp.net...
> >
> > The "yellow zone" is an attempt to improve on all that. It's essentially
> > another red zone to start with. Except that when the zone is "violated" by
> > stack incursion, it's changed to "green". This gives an extra page (or
> two,
> > or whatever is necessary) for the thread to handle the situation, either
> by
> > delivering a signal or raising an exception. Ideally, if the event is
> > cleanly handled, the yellow page(s) will be automatically "painted red"
> > again by the OS when the stack is unwound into the green zone. (Tru64 UNIX
> > works this way; OpenVMS, which also has yellow zone, doesn't convert a
> used
> > yellow page back to red.)
>
> What kind of exception is thrown when you hit the yellow/red zone?
Whatever[1] is thrown, personally, I can't really COMPREHEND
how to deal with it... if it happens to occur invoking/inside
some NOTHROW call, I mean.
Perhaps someone could help me. PLEASE. TIA.
regards,
alexander.
[1]
http://groups.google.com/groups?selm=c29b5e33.0202161451.2ef75f1f%40posting.google.com
"Herb Sutter <hsu...@acm.org> wrote in message
news:<jtas6uggftq6lt2o3...@4ax.com>...
[...]
> Yes, but you can have the nothrow guarantee whether the exception
> specification says so or not. In fact, I usually write declarations
for such
> functions like this: "X f( Y ) // throw()".
And who is protecting your clients from really bad
things (exceptions/faults) along the lines of:
< NO answer from Mr. Sutter... yet.. here is @ *MICROSOFT* now, BTW >
From the URL above:
"....
pthread_stackovf_e Attempted stack overflow was detected
...."
http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V51A_PDF/ARH9RBTE.PDF
("Tru64 UNIX|Guide to the POSIX Threads Library")
"....
A guard area, with its associated overflow warning area,
can help a multithreaded program detect overflow of a
thread's stack. A guard area is a region of no-access
memory that the Threads Library allocates at the overflow
end of the thread's stack, following the thread's overflow
warning area. If the thread attempts to write in the
overflow warning area, a stack overflow exception occurs.
Your program can catch this exception and continue
processing as long as the thread does not attempt to
write in the guard area. When any thread attempts to
access a memory location within the guard area, a memory
addressing violation occurs without the possibility of
recovery.
...."
Well, I'm surely missing something here... but without
C++-like EXCEPTION SPECIFICATIONS "fences" (especially
for NOTHROW calls -- throw(), I mean... and *including/
fencing the parms/args: foo( *...PARMS...* ) throw(),
I guess, BTW), "blind" unwinding on stack overflow fault
is just an invitation for even more troubles, I'm afraid.
Unless it is known for sure that a) stack overflow
exception could indeed be thrown from the point of fault
and b) it's really EXPECTED -- there is some matching
catch handler "waiting" for it... invoking C++ terminate()
handlers instead at "throw" point (for emergency inter-
process cleanup stuff) would seem MUCH more reasonable
to me...
Or am I wrong, folks?