i’ve heard of something from 10’s to a few 100 bytes (esp on platforms
like IA64). There is another side affect from using SEH…the optimizer
is severely limited in what it can do inside the __try block. the
optimizer can’t know which instruction/call will throw an exception, so
it basically gives up. If that is an acceptable trade off so be it, but
that is usually a big show stopper for most folks.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Ward
Sent: Wednesday, December 07, 2005 4:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ZwQuerySystemInformation crash
Mark Roddy wrote:
SEH has massive stack overhead, even in the limited case of
try/leave/finally with no exception handler. It was the stack
overhead,
I’m curious. How much is “massive”? i.e. if I add a __try … __finally
round
the outside of a function, by how many bytes does it’s stack usage go
up?
Sure, I could measure it myself, but you must have already done that.
On a separate point, the replacement of __try … __finally with macro
calls that look the same but have different semantics makes me nervous.
(What do I mean by different semantics? Consider what happens if a
maintainer inserts a return into the TRY … FINALLY block).
If you always maintain your stuff, it probably isn’t a problem but we
can all recall cases where later maintainers just thought they knew
what macros did without looking at the definitions because “it was
obvious
from the name”. I would fear that TRY and FINALLY are an accident
waiting to
happen (unless, as I said, you do your own maintenance).
Don
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com