Subject: Signal handling... now 2.2 is out the door...

From: Chris Rankin <[email-masked]>
Date: Thu, 6 May 1999 22:01:07 +1000 (EST)

Hi,
It's SO nice to be back online! About 3-4 months ago I partially
upgraded the FVWM signal handling. However, finishing the job required
more code than the pre-2.2 version could really handle. That has now
changed :-) !

I have a (POSIX.1) file which wraps the select() system call to remove
the race-condition that currently exists. In theory, the same strategy
can be used to wrap any other calls which might block during the
event-loop. Anyway, the logical course of action would be to put this
file into libfvwm.a so that all FvwmModules can use it, followed by
MAKING them use it. Of course it's not quite as simple as that since
the module is bound up with the isTerminated flag and the 
TerminateHandler, but I hope you get the idea.

How many other platforms besides POSIX.1 are we supporting? More
importantly, how many of these platforms modify the process's signal
mask before handling a signal? Things are particularly nice and
reentrant with POSIX.1, and I'd like not to break that.

The signal code in FVWM 2.2 looks pretty much the same; is there
anything I should know before I start hacking :-) ?

Great job getting 2.2 out, people,
Cheers,
Chris.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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: Dominik Vogt <[email-masked]>
Date: Thu, 6 May 1999 21:21:58 +0200

> more code than the pre-2.2 version could really handle. That has now

Nice to see you back, Chris.

> reentrant with POSIX.1, and I'd like not to break that.

I don't know if VMS is POSIX. Probably not.

> anything I should know before I start hacking :-) ?

Nope, we didn't do much with signal handling. BTW, your patches
fixed swallo/unswallow in FvwmButtons nicely. Good work.

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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: Steve Robbins <[email-masked]>
Date: Fri, 7 May 1999 00:31:41 -0400 (EDT)

> anything I should know before I start hacking :-) ?

I dunno.  But here's something related to signals that I believe needs to
be changed.

ReadFvwmPacket (libs/Module.c) is used by modules to read a packet from
FVWM.  For some reason that I cannot fathom, rather than returning an
error code signifying "end of file", this *library* function does a
callback to a function named "DeadPipe".  

Why does ReadFvwmPacket signal errors and "end of file" in this strange
way, rather than, say, returning <= 0 like read()?  As I say, I don't know
why it works this way.  My guess is that this was an easier hack.  The
end-of-file condition is taken to indicate that FVWM has gone away, so
calling a "dead pipe" handler from the library is easier than making sure
all the module code checks return values correctly. 

Why is this a problem?  If you want to build libfvwm as a SHARED library,
then *every* binary linked with it needs to have DeadPipe() whether used
or not.  Even the stuff in utils, like xpmroot.  That's not good.

There are a few ways that I can see to clean this up.  One is to give
ReadFvwmPacket() the semantics of read().  Namely, it returns 0 at
end-of-file, and -1 on error.  This seems clean to me, although it puts
one at the mercy of module writers who don't check error conditions.

Another way around this could be to have the library code itself send the
process a SIGPIPE.  Currently, the DeadPipe routine is almost invariable
*also* used as the signal handler for SIGPIPE.  So: what is wrong with
generating a signal yourself in ReadFvwmPacket? 

--
Steve Robbins                              <[email-masked]>

Speeding motorcycle ... won't you take me ...

---

From: Dan Espen <[email-masked]>
Date: Fri, 14 May 1999 16:28:32 -0400

> generating a signal yourself in ReadFvwmPacket? 

So many of these questions remain unanswered...

At first I thought we might have persistent modules that don't bother
to read the Fvwm pipe.  Perhaps I found one, FvwmScroll?  Thats not to
say that I think thats its OK for modules not to be reading the fvwm
pipe.  Seems to me, if they don't, theres going to be some memory
used up.

I'm not sure about the DeadPipe symbol having to be resolved.  Isn't
that based on the LD_BIND_NOW setting?

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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: Steve Robbins <[email-masked]>
Date: Sun, 16 May 1999 09:27:57 -0400 (EDT)

On Fri, 14 May 1999, Dan Espen wrote:

> to read the Fvwm pipe.  Perhaps I found one, FvwmScroll?  

Aha, good point.  It didn't occur to me that this might happen.

So, assume that persistent modules not reading the pipe (or even closing
their pipe?) is legitimate.  When FVWM shuts down, we need to communicate
to them this fact.  How?  Shouldn't we try to send them signals?  Maybe
use init's strategy of "killing them softly", wait a bit, then get more
and more agressive?

> Thats not to

Are you thinking of the memory used up in pipe buffers?  How about closing
the pipes?
 
> that based on the LD_BIND_NOW setting?

I know nothing of LD_BIND_NOW.  I've never heard of it; please elaborate.

All I know is: I built a shared libfvwm.  Most of the modules & stuff
linked fine, but some crapped out because they don't export a DeadPipe
symbol.  This is on linux 2.0.35.

When love is gone, there's always justice.
And when justice is gone, there's always force.
And when force is gone, there's always Mom.

---

From: Tim Phipps <[email-masked]>
Date: Mon, 17 May 1999 09:05:00 +0100

> to read the Fvwm pipe.  Perhaps I found one, FvwmScroll?

Nice try, but no cigar.  FvwmScroll now reads the fvwm pipe so that it
an update it's colors dynamically.

Cheers,
Tim.

---

From: Dan Espen <[email-masked]>
Date: Mon, 17 May 1999 08:59:05 -0400

> use init's strategy of "killing them softly", wait a bit, then get more

Ah, but I don't assume that not reading the pipe is legitimate.
I was just reaching for an explanation of the current architecture.

> Are you thinking of the memory used up in pipe buffers?  How about closing

Yes, thats the  memory I was thinking  of.  I'm not sure  I understand
the part about closing the pipes, my guess  is all modules should read
the pipes.  (From Tim's comment, I guess they all do now.)

>From man ld.so.1 on Solaris 2.6:

     LD_BIND_NOW    The runtime linker's default mode of perform-
                    ing lazy binding can be overridden by setting
                    the environment variable LD_BIND_NOW  to  any
                    non-null  value. This setting causes the run-
                    time linker to perform  both  data  reference
                    and  function  reference  relocations  during
                    process initialization,  before  transferring
                    control  to the application.  Also see the -z
                    now option of ld(1).

I first ran into this with a user that had  this set, but couldn't run
one of our  applications.  Turned out  a Solaris shared  library had a
symbol   that couldn't  be  resolved  by  any  other shared   library.
Unsetting this variable "fixed" the problem.

> symbol.  This is on linux 2.0.35.

If  you got errors,  not warnings, I'm  off  base on  this.  Again, my
comment was based  on the runtime experience  above.  I don't know how
the shared library in question got created.  Also, I  only saw this on
Solaris.

---

From: Steve Robbins <[email-masked]>
Date: Sat, 22 May 1999 17:09:19 -0400 (EDT)

On Mon, 17 May 1999, Dan Espen wrote:

> If  you got errors,  not warnings, I'm  off  base on  this.

I got errors.  They were from the linking step, not the runtime loader ---
it didn't even produce binaries. 

I suppose this means we cannot expect systems to have lazy binding like
solaris does.  So we need to resolve the DeadPipe somehow.  

So let me propose that ReadFvwmPacket() be fixed to conform with its
documented behaviour (see libs/Module.h):

 * Returns:
 *   > 0 everything is OK.
 *   = 0 invalid packet.
 *   < 0 pipe is dead. (Should never occur)

Execept that <0 returns *will* happen, precisely when FVWM shuts down.

The main objection that I can see to this approach, is that you must now
rely on module-writers to check the return value properly.  Perhaps this
is too much to ask?  

I'm not overly concerned by this.  I don't run many modules, and I'll go
through and fix the modules in the FVWM tree.  However, I think that the
"right" thing to do would be for FVWM to explicitly send signals to child
modules when it is shutting down.  Something like the way init does
things. 

Would this be a bad idea?

Would we want to try killing all children of FVWM, or just the modules?

---

From: Dan Espen <[email-masked]>
Date: Sat, 22 May 1999 19:49:41 -0400

Steve Robbins <[email-masked]> writes:
> So we need to resolve the DeadPipe somehow.  
> 
> 

No way is it too much to ask.  Whatever rules we set, if someone wants
their module to run, they have to follow the rules.  This one seems
pretty easy.

> Would this be a bad idea?

Send signals instead of  letting the pipe go dead?   It does  have the
flavor  of being "right",  but right now, I  don't think  it makes any
difference.   If its a  "bad" idea, I  don't  see the reason.  (Think,
think.)

> Would we want to try killing all children of FVWM, or just the modules?

You mean all the applications started by fvwm?  I wouldn't want
that, I frequently exit fvwm2 and come back in thru xprompt in order
to switch fvwm2 versions.

---

From: Steve Robbins <[email-masked]>
Date: Sun, 23 May 1999 09:07:20 -0400 (EDT)

> > However, I think that the
> Send signals instead of  letting the pipe go dead?

It would be signals in *addition* to closing the pipe.

> to switch fvwm2 versions.

Ah, right.  It's only the modules that need to be shut down.

---

From: Tim Phipps <[email-masked]>
Date: Mon, 24 May 1999 11:14:37 +0100

> Would this be a bad idea?

What happens if fvwm crashes or gets killed?  Maybe my set up is unusual
in that fvwm quitting doesn't kill the Xserver and I can usually get
fvwm started again, but it would be a big pain in the neck if my load
average went up to 6 when fvwm crashed because 6 modules went into a
read-nothing-very-fast loop

Cheers,
Tim.

---

From: Steve Robbins <[email-masked]>
Date: Mon, 24 May 1999 09:25:07 -0400 (EDT)

> read-nothing-very-fast loop

Indeed, that would be a Bad Thing.

What happens to the modules if FVWM crashes In the current scheme?  I
presume, without checking, that the answer is that the module detects
FVWM's absence the next time it reads the pipe, perhaps by calling
ReadFvwmPacket().  My proposal doesn't change the essence of that; it
does, however, shift the onus of error checking to the caller of
ReadFvwmPacket(). 

Fixing the ReadFvwmPacket() calls in distributed modules is a piece of
cake.  There is, however, a legitimate concern about silently breaking
existing 3rd party modules. 

So let me modify the proposal.  Instead of changing the semantics of the
*existing* ReadFvwmPacket() interface, I propose to remove it, and replace
it with equivalent functionality under a new name.[1]  This way, the 3rd
party modules will break during recompilation & will get the required fix. 

At the same time, why not view the packet as a struct, rather than an
array of unsigned longs?

The new function proposed is: 

    fvwm_packet_t* GetFvwmPacket( int fd );

The return value is a newly-allocated FVWM packet, to be freed by the
caller.  [This is a copy of the existing "malloc the packet body" 
approach.  Alternatively, we could -- for speed? -- return a pointer to
static storage and require modules to copy needed info before calling
GetFvwmPacket() again.]

A NULL return indicates the source of packets (i.e. FVWM) has
gone away, so the module should clean up & exit.

/**
 * Packet sent from FVWM to modules.  This structure has variable size.
 **/

typedef struct {
    unsigned long start_pattern;
    unsigned long type;
    unsigned long size;    /* number of "unsigned long"s in packet */
    unsigned long timestamp;
    unsigned long body[];
} fvwm_packet_t;

---- 

1. Actually, since we are changing the number & type of arguments, perhaps
changing the prototype of ReadFvwmPacket() is enough to cause compile
errors for 3rd party modules.  Then we can keep the existing function
name, rather than renaming it GetFvwmPacket().

---

From: [email-masked] (Paul D. Smith)
Date: 24 May 1999 10:13:28 -0400

%% Steve Robbins <[email-masked]> writes:

  sr> /**
  sr>  * Packet sent from FVWM to modules.  This structure has variable size.
  sr>  **/

  sr> typedef struct {
  sr>     unsigned long start_pattern;
  sr>     unsigned long type;
  sr>     unsigned long size;    /* number of "unsigned long"s in packet */
  sr>     unsigned long timestamp;
  sr>     unsigned long body[];
  sr> } fvwm_packet_t;

Not sure if you were just using psuedo-code or not, but note the last
field isn't legal C (yet... this feature is proposed for C9x).  You'd
need:
    
  unsigned long body[1];

then do the calculations (subtract 1 when allocating, etc.) in the code.

Also, FYI, this method (called the "struct hack") has been determined to
not be valid standard C--although it does work on every system I've ever
used, and I do use it myself, regularly :).

  sr> 1. Actually, since we are changing the number & type of arguments,
  sr> perhaps changing the prototype of ReadFvwmPacket() is enough to
  sr> cause compile errors for 3rd party modules.  Then we can keep the
  sr> existing function name, rather than renaming it GetFvwmPacket().

I like this.

-- 
-------------------------------------------------------------------------------
 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.fvwm.org/>.
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]