call_handler, interrupt_now and interruptible
Thu Feb 3 15:25:00 GMT 2000
On Thu, Feb 03, 2000 at 06:38:43PM -0000, Fifer, Eric wrote:
>"Ray Easton" writes:
>>> Anyways, is this dangerous to do?
>>If 'this' means interrupting a DLL while it is "paused on a system
>>call", yes, it is extermely dangerous and can leave the NT kernel in a
>>corrupt state. (This has nothing to do with Cygwin -- this is purely
>>an NT issue.)
>Actually, by 'this' I meant comment out 'pchigh == 0x60000000'. And,
>when I wrote 'system call' I meant a Cygwin system call like read, but
>since most things are emulated on top of Win32 calls, eventually there
>might be a Win32 call like ReadFile. AFAICT, Cygwin signals are emulated
>with Win32 threads and semaphores. A Cygwin process has a "sig" thread
>and a "main" thread, when a signal is sent, the "sig" thread receives it,
>does a SuspendThread on the "main" thread and does a GetThreadContext,
>if it is "interruptible" the context is changed and the signal handler
>is pushed on the stack and the new context is set with SetThreadContext
>then followed by a ResumeThread. I can see how this could be dangerous
>although I'm fairly ignorant of Win32, so I'm not sure exactly what you
>can do that will leave the NT kernel in a corrupt state.
The answer to your question is that this *is* dangerous to do. It allows
cygwin "system calls" to be interrupted.
The code that you are investigating is essentially a stopgap until such
time as I have time to make it more foolproof.
As you've discovered, if you are using a snapshot, you're living on the
Want to unsubscribe from this list?
Send a message to firstname.lastname@example.org
More information about the Cygwin