call_handler, interrupt_now and interruptible

Chris Faylor
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

More information about the Cygwin mailing list