David,
Thank you for your message which I guess started from the
internet-history list, not the ietf discussion list.
... Lots of programs compile code into a temporary buffer and then execute
it. The most interesting ones that I know of are in graphics support,
where various bitblt's and other highly parameterized, highly loopy code
process a lot of data.
So, locking the stack against execution would slow graphics applications?
Maybe someone should let Intel know, since they are having a hard time
convincing consumers that 2 GHz > 1 GHz. It is pathetic how audio
applications have been ignored. Swaying my opinion would require a
different example.
Putting the temporary buffer on the stack is *good*
design, not bad - using a static buffer requires unnecesary locking, and
allocating with malloc() means handling the possibility of an "out of
memory" in a sensitive part of the system....
On the contrary, there is nothing wrong with a seperate code stack in its
own segment.
Cheers,
James