Re: [Bug foound/Suggested Solution] Suspending on linux Console and lingpm
Ian T Zimmerman <itz(a)rahul.net> writes:
No it won't, not on my system (ix86, kernel 2.0.35, libc 5.4.44).
Do
you use glibc?
Yes I do. However we have been seeing these bug reports for quite some
time now on XEmacs. I guess even before the big move towards glibc2.
So there must be something else happening too (or my recollection is
wrong/all these bug reports were from glibc early adopters).
So like I commented the code was written for a different signal
behaviour and you think this changed during the libc5->libc6 change
over.
That may be the root of the trouble. Otherwise I'd
suspect the way you have compiled libgpm (maybe you added
-D_USE_BSD?)
I am fairly sure some versions ago XEmacs used those flags on Linux.
Could it be that for some reason using this flag in the application
breaks the library too? I am not at my linux system so I cannot check
what the mechanism is.
> Note. Signal handlers installed with 'signal' are
called with the
> signal that generated them blocked. It is then unblocked on exiting
> the signal handler.
>
No. Under ix86 Linux up to and including 2.0 (don't know about 2.1,
but
I am not sure but I am fairly certain that on every glibc6 system (and
there are quite a few now) the signal() behaviour is now as I
described and therefore libgpm is broken there. I was confused in
thinking this was universal because the Solaris 2.x 'signal' manpage
also decribes the 'bsd' behaviour.
I won't be fixing gpm to be compatible with a development
kernel),
All the bug reports we had were from people running stable Kernels. So
at the very least you would have to deal with 2.0.x+glibc2.
> Here the signal handler exits. The SIGTSTP handler is unblocked
and
> any queued signals are sent including the one we sent
> outselves. Bingo! we now have a sinal loop. The process will hang
> sucking up 100% of CPU.
>
See above.
On my glibc2 system this is happening for sure.
OK, this should work even if your system's signal semantics is
different for some weird reason. I'll add it is soon as I can get
back.
(Using sigaction with SA_NOMASK will have the same effect and
will make the intent a bit clearer).
Ok thanks. It will kill off a lot of bug reports in the future.
> 2. The SIGWINCH handler just above it just calls the old
signal
> handler direct. That obviously works. May I suggest however
> that a more complete prototype is used for the signal handler.
You'd need special cases for SIG_DFL and SIG_IGN. Ugly.
Note that you already special case SIG_IGN when installing the
handler.
What's this BSD stuff?? Are we talking Linux or not? See above about
gpm compilation.
I was being confused by both the Solaris and the glibc2 docs (or at
least the man paged derived from it for the Debian distribution)
describing 'signal' as a BSD compatibility layer over sigaction.
> I would like a combination of 1 and 5. With 5 being low
priority so
> it can wait till there actually is a client that needs it.
OK, agreed, I'll do [1] ASAP.
Thank you very much.
Jan