From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,5a05d88755a62a0e
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Asynchronous Transfer of Control
Date: 1996/10/18
Message-ID: <DzHJ9z.K1q@world.std.com>#1/1
X-Deja-AN: 190360830
references: <32656457.1A76@csehp1.mdc.com>
 <DzF1Fo.CJs.0.-s@inmet.camb.inmet.com> <DzFAMr.6DG@world.std.com>
 <DzH5n3.2rE@thomsoft.com>
organization: The World Public Access UNIX, Brookline, MA
newsgroups: comp.lang.ada
Date: 1996-10-18T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <DzH5n3.2rE@thomsoft.com>, Ken Cowan <cowan@east.alsys.com> wrote:
>Give ObjectAda for Windows a try.  It does preemptive abort without
>polling.  It's implemented by suspending the thread, then
>resuming it at some run-down code.  For ATC, the run-down code
>longjmp's back to the correct place.  For an abort, it finalizes
>everything and terminates the thread.

OK, that proves it can be done, but I'm still curious as to how it
works.  I don't remember reading about any "resume at some particular
place" primitive in the win 95 documentation I've read.  Which system
calls, exactly, are being used?  Or does the Ada RTS poke the saved PC
value of the thread, so it will resume at a different spot?  If so, is
there a documented way of getting at the saved PC (and other thread
registers).

(By PC I mean EIP, of course, on 80x86.)

- Bob