Lists: | pgsql-hackers-win32 |
---|
From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
---|---|
To: | "Magnus Hagander" <mha(at)sollentuna(dot)net>, "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> |
Cc: | "Steve Tibbett" <stibbett(at)zim(dot)biz>, "pgsql-hackers-win32" <pgsql-hackers-win32(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] [PATCHES] fork/exec patch |
Date: | 2003-12-16 18:52:32 |
Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCE2A6940@algol.sollentuna.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers-win32 |
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 means that as soon as the main thread gets back into userspace, it
will throw an EXCEPTION_ACCESS_VIOLATION.
Then you have to wrap the entire backend in a
__try
backend goes here
__except
Then in the exception handler, you have to check that it was the correct
ACCESS_VIOLATION, do the signal handler, and then tell the exception
handler to continue working where it last was
(EXCEPTION_CONTINUE_EXECUTION).
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.
This is messy... :-)
//mha