Subject: Re: Fixed patch for FvwmIconMan

From: [email-masked] (Paul D. Smith)
Date: 18 Dec 1998 02:23:46 -0500

Hi Chris;

I think it's great that you're taking this project of making fvwm and
modules more signal-safe.  Sorry I haven't spoken up before; I've been
trying to find the time to see what you've been doing.

I do have some concerns about these changes: mainly that you're using
possibly non-portable functions.  All the items you're using are POSIX,
that's true, but even today more systems support the current signal(),
etc. feature set than do sigaction(), sigsetjmp(), etc.

I'm worried that we'll be sacrificing portability to some older
platforms by accepting these changes.  Mainly I wonder if these kinds of
changes are appropriate so close to the official release; while they
certainly improve the robustness on platforms that support these items I
wonder if we have enough time and testing left to ensure there won't be
problems.

What I'd like to see is someone go take a look at how signals are
handled in other very portable GNU apps; that's how I usually tell
what's portable and what isn't.  There may be configure-time switching
or something that can be done to get decent behavior both on POSIX and
non-POSIX systems.

Also, I think I see from your patches how you intend this to work, but
I'd really appreciate a writeup from you on the details so we can all
take a look; this may well get folded into the HTML docs for module
developers, if we come up with a standard, portable, robust way to deal
with these issues.

Or, it might be better to create some libfvwm functions to handle this.
Other thoughts?

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

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

> modules more signal-safe.>

Necessity is the mother of intervention: FvwmButtons currently doesn't
clean up after itself...

> etc. feature set than do sigaction(), sigsetjmp(), etc.

...

> handled in other very portable GNU apps;

Someone has already suggested checking out the SAMBA source. But if
there is a way to move forwards with POSIX.1 I'd like to pursue that -
if the UNIXes in question are REALLY old (read: broken) then trying to
get everything robust and signal-safe is likely a dead horse.

> developers, if we come up with a standard, portable, robust way to deal

Actually, a change-of-direction is in order, which will help make
everything more portable into the bargain (isn't that nice?). There's
a catch, of course.

Detailed study of my UNIX reference and the HP-UX man pages pointed
out that siglongjump() DOESN'T solve the reentrancy problem unless you
KNOW that nothing non-reentrant has been called between the
sigsetjmp() and siglongjmp() calls. Doh! So it's time for Plan B:

static void DeadPipeHandler(int sig)
{
  isTerminated = True;
}

and then rewrite the main event loop to:

while ( !isTerminated ) { ... }

rather than:

while (1) { ...}

This works and is portable, BUT means that you must check the return
code from EVERY system call such as "select", and anything which could
block, so that you can provide a fast-track exit the moment
isTerminated becomes True. There are several places in the code where
people have assumed that select() with an indefinite time-out will
never fail.

I have mapped out a (POSIX.1 unfortunately) wrapper strategy for
potentially-blocking such that you can ATOMICALLY perform the
following:

if ( !isTerminated ) select();

I tested it this afternoon by putting "raise(SIGUSR1)" lines
everywhere and it survived so I'm reasonably confident. Of course,
this bulletproof(?) wrapper stuff is way too late for 2.2, but I think
that the basic "isTerminated = True" signal handlers will prove
reliable enough for now.

Comments anyone,
Cheers,
Chris.

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 19 Dec 1998 01:34:56 +0100

Since this is becoming a protability issue, Paul (PDS), would
you take care of applying new or backing out old patches?
I've applied four of the five signal handler patches from
Chris except the one to FvwmIconMan.

I can't help here much with details, but in general my opinio is:
I am willing to risk breaking some setups even so close to a release
(looking at Jitterbug and the to do list the release is probably
farther away than we hoped). But in the end I think aven old systems
should run. That's what autoconf is good for, isn't it.

Bye

Dominik

P.S.: I'll be busy with the MenuStyle rewrite in the next few
days, so if someone else would take on apllying patches/bugfixed
I will be grateful.
-- 
Dominik Vogt, [email-masked]
Reply-To: [email-masked]