Instead of constaining the use of event-detour so much, make it merely
unlikely that the detour will have to allocate when used in a loop
that otherwise doesn't allocate. We'll only have to allocate if the
available stack space turns out to be too small --- and if we do
allocate, it's not the end of the world.
original commit: f1dbed82df415c18c8304bedcee2ecf4912badc7
Having the trap check allocate is questionable, since it can be
triggered during a loop that otherwise performs no allocation. Also,
on platforms where at most 1 argument is passed in a register, then
sending two arguments to the event handler could potentially need
stack space that isn't there. So, constrain the smaller trap-check
code to cases where no stack space is needed and where no allocation
happens unless the wrong number of arguments are provided.
original commit: 260a7ef5bc0bf851d9848587b0a78bdb4aab59f8
When a proceudre starts with a trap check, move the check to the very
beginning, even before checking the argument count. That way, event
detection can turn into a compact jump to an event handler, instead of
inserting a general call to `$event` in the procedure body.
original commit: 06b12d505698a2378734689370bb9e0f8eda06b9
If normal 1-shot continuations are mixed with opportunistic 1-shot
continuations created by `call-setting-continuation-attachment`, then
promoting an opportunistic 1-shot at a GC is wrong unless the whole
chain is promoted.
original commit: 2dfac475666763b60935e382386af4438f3029e0
allocating the thread context fails from Sactivate_thread. before
this change, the error was raised on the main thread, which resulted
in strange behavior at best. also added who argument to
S_create_thread_object to allow it to report either Sactivate_thread
or fork-thread led to the error.
externs.h, schsig.c, scheme.c, thread.c
original commit: 89691cee27ee7d5e9bffae530b6346e96f8cc7ad
