Re: feature tests for pthreads implementation and configuration?

In article <442a5514$1@xxxxxxxxxxxxxxxxx>,
Mikael Pettersson <mikpe@xxxxxxxxxxxxxxx> wrote:
In article <44295B83.748ED644@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Kasper Dupont <32013571368912025171@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Mikael Pettersson wrote:

A no-no, yes, but not a bigger one. Our JITed code runs on stacks
that grow as needed via compiler-inserted overflow checks. That's
why signal handlers (C code not following this protocol) must be
redirected to alt stacks.

Couldn't the overflow check discover large stack usage early
enough to ensure there would still be enough space available
for a signal? (I guess you can figure out what the maximum
stack usage for your handlers is).

No we can't know with 100% accuracy which signals are being
caught or what their handlers are up to.

Correction: we do detect dynamically which signals are being caught,
so that we can enfore SA_ONSTACK for them, but we still have little
or no control over their handlers.
--
Mikael Pettersson (mikpe@xxxxxxxxx)
Computing Science Department, Uppsala University
------------ And now a word from our sponsor ---------------------
For a secure high performance FTP using SSL/TLS encryption
upgrade to SurgeFTP
---- See http://netwinsite.com/sponsor/sponsor_surgeftp.htm ----
.

Relevant Pages

  • Re: feature tests for pthreads implementation and configuration?
    ... Our JITed code runs on stacks ... stack usage for your handlers is). ... No we can't know with 100% accuracy which signals are being ...
    (comp.os.linux.development.apps)
  • Re: two-argument operations?
    ... (Anton Ertl) ... using callbacks may have to create and destroy Forth stacks very fast, ... the callback handlers have no access ... the case of asynchronous callbacks, ...
    (comp.lang.forth)