Re: [HACKERS] [PATCHES] fork/exec patch

> Arrgh - hit send too fast!
>
> >BTW, for the record, here is a quick view of how to make
> >actual interrupting calls into another thread. I think you can
> >see why I do't think that's a really good option..
> >
> >When calling the signal, run:
> >SuspendThread(mainThread);
> >GetThreadContext(mainThread);
> save away IP
> change IP of context to a *known invalid address*
> SetThreadContext(mainThread);
> ResumeThread(mainThread);

This then is a variation of having signals execute from within the main
thread but without waiting for the main thread to ask if there is any
waiting signals.  Actually, this is closest to Unix signals in behavior
despite the crude method of implementation.

However, this:
> Downside? This one does *not* fire if the thread is "stuck" in a
kernel
> call such as.. Yes. WaitForSingleObject(), etc - just the sam eones
that
> the other solution requires.
is a killer because this will cause problems with I/O completion ports
if and when they are implemented.  I understand the prevailing train of
thought here, but I suspect at some point in the future the win32 port
may move in this direction so this has to be carefully considered.

I mentioned this:
> __try
>   backend goes here
> __except
several months ago wrt win32's non standard handling of integer/0 (try
it on the peerdirect port) and got a 4 word reply from a mr. Tom Lane:
"that is not C" which I still think is humorous :).

Merlin