Mail Archives: cygwin/1997/09/25/17:52:49
The current signal handling code processes signals in the user's thread.
If signals were processed in a separate thread I don't think that
Windows95 would have a problem:
1. suspend user thread (don't care whether or not it is doing
system stuff)
2. invoke signal handling
3. resume user thread
Unfortunately there is software that assumes that signals are processed
in the user's context - functions like longjmp will only work if signals
are processed in the user's thread.
There some (posix?/sysv?) API functions that allow an application to
specify whether or not signals are handled in the user's execution
context.
Alex wrote:
>
> On Wed, 24 Sep 1997, Sergey Okhapkin wrote:
>
> > Mikey wrote:
> > > perhaps the following Psuedocode fragment will
> > > give you some workable ideas.
> > >
> >
> > This may not help. Signal processing thread must suspend main thread
> > execution and switch it to signal handler routine. The only way to do it I
> > see is the current method (originally designed by Steve Chamberlain, the
> > inventor of gnu-win32 project): suspend the main thread execution, save
> > current inctruction pointer, set it to signal handler address and resume
> > main thread. Win95 may hang if context switching is while in a syscall. Why
> > did it work before? Because all the signal mechanism was almost missing in
> > cygwin.dll.
>
> What about checking to see if you are making a call that could hang Win
> and then either a.) waiting for the syscall to finish or b.) interrupt
> that call?
>
> - alex
>
> -
> For help on using this list (especially unsubscribing), send a message to
> "gnu-win32-request AT cygnus DOT com" with one line of text: "help".
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -