Subject: Apology to all (Was FVWM: Updates to previous patches (v2.1.5))

From: "Rankin, Chris" <[email-masked]>
Date: Wed, 16 Dec 1998 17:10:58 -0500

Oops! Looks like I've been cluttering up the discussion group! Sorry
everyone.

Chris.

(Could have been worse, though - imagine if fvwm@ had been the
"announcement" list ;-) !!)

> ----------
> From: 	Tak[SMTP:[email-masked]]
> Sent: 	Wednesday, December 16, 1998 5:05 PM
> To: 	Chris Rankin
> Subject: 	Re: FVWM: Updates to previous patches (v2.1.5)
> 
> hey, can you send these to fvwm-workers only please? ;)
> 
> -tak
> 
> 
--
Visit the official FVWM web page at <URL: http://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Adam L Rice <[email-masked]>
Date: Thu, 17 Dec 1998 11:14:16 +0000

> Oops! Looks like I've been cluttering up the discussion group! Sorry

No need to apologise--the patches were very instructive, and it's nice to
see some traffic around here :-) I'm impressed that you were able to clean
up the signal handling with so little code--when I was reading the bug
tracking reports, it looked like that was gonna be a doozy to fix.

I'm curious about the portability of using longjmp to get out of a signal
handler, though--don't some platforms use a seperate stack for signal
handlers? And do all current BSD systems possess sigaction?

-- 
Adam Rice -- [email-masked] -- Blackburn, Lancashire, England

---

From: Chris Rankin <[email-masked]>
Date: Fri, 18 Dec 1998 09:09:41 -0500 (EST)

> handlers?

I am under the impression that "siglongjmp" is a variant *explicitly*
designed to be called from within a signal handler. Such
implementation details as switching stacks should be handled
internally by the system. Therefore if it has "siglongjmp", it should
work. Plain "longjmp" has no such guarantee.

> And do all current BSD systems possess sigaction?

That's a good question. I had assumed that POSIX 1 was prevalent in
the modern UNIX world. I have programmed on Linux, HPUX, Solaris and
AIX and all these platforms have provided POSIX 1.

There is an alternative *but less robust* way of improving the signal
handling that involves having a "static volatile sig_atomic_t
isDeadPipe" variable, which is set to "True" within the signal
handler. This approach wouldn't need to block other signals since
multiple handlers could set the variable to True as often as they
wished. The point of the variable would be to control the event loop
so that "while (1) { ... }" would become "while ( !isDeadPipe )
{ ... }". The problem with this approach is that it's less responsive
unless you preface every call which could block with "if
(!isDeadPipe)":

Consider: a signal arrives just AFTER checking isDeadPipe in the main
event loop but BEFORE the call to My_XNextEvent(). Or possibly a signal
arrives in My_XNextEvent() before the call to select(). The isDeadPipe
variable suddenly becomes True, but the process blocks anyway and
needs another signal or something to free it. This is why I took the
siglongjmp approach - it FORCES the termination issue.

If anyone has a system that does NOT have POSIX 1 support (bear in
mind that POSIX 1 support may not appear until you #define
_POSIX_SOURCE) can they speak now, please?

Chris.