From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Faylor To: "Fifer, Eric" Cc: "'Ray Easton'" , cygwin@sourceware.cygnus.com Subject: Re: call_handler, interrupt_now and interruptible Date: Thu, 03 Feb 2000 15:25:00 -0000 Message-id: <20000203182621.B2383@cygnus.com> References: <779F20BCCE5AD31186A50008C75D99791716D3@SILLDN_MAIL1> X-SW-Source: 2000-02/msg00043.html 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 edge. cgf -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com