Subject: FVWM: Proposal: M_FVWM_EXIT packet type

From: "Randy J. Ray" <[email-masked]>
Date: Fri, 14 Mar 1997 15:30:42 -0700

Having delved much more deeply into the modules code, it seems that the modules
all use a processing loop derived from the same base, and that said loop does
poll (using select()) the output fd, to see that it is still writable, exiting
when it isn't.

Well, this probably won't work for a lot of other event-driven applications
besides my own exploration with Perl and Tk. A C application using the Xt or
Xm toolkits is likely to pass it's control to an event loop, and rely on
bound callbacks for handling all eventualities.

So perhaps a good idea would be a packet type of M_FVWM_EXIT (or just M_EXIT,
or similar) that is sent to all modules (regardless of mask, since this is a
fairly noteworthy event) by the Done() routine, before it closes the pipes.
This way, modules that care about exit events can respond to them-- a module
that is keeping some sort of running data can save it's data before exiting,
or a run-time configurable module could save it's current state. Most 
importantly, modules using a higher-level event loop, such as Tk-driven or
X Toolkit-driven, can opt to route a handler for this packet.

Just a thought.

Randy
--
===============================================================================
Randy J. Ray -- U S WEST Technologies IAD/CSS/DPDS         Phone: (303)595-2869
                Denver, CO                                     [email-masked]
"It's not denial. I'm just very selective about the reality I accept." --Calvin
===============================================================================
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: "Barry A. Warsaw" <[email-masked]>
Date: Fri, 14 Mar 1997 18:21:13 -0500

>>>>> "RJR" == Randy J Ray <[email-masked]> writes:

    RJR> Well, this probably won't work for a lot of other
    RJR> event-driven applications besides my own exploration with
    RJR> Perl and Tk. A C application using the Xt or Xm toolkits is
    RJR> likely to pass it's control to an event loop, and rely on
    RJR> bound callbacks for handling all eventualities.

My own Python/Tk modules uses tkinter.createfilehandler()
(i.e. Tcl_CreateFileHandler()) to dispatch on data available from the
fd Fvwm is writing to.  Seems like this works well, and my module does
know when Fvwm is exiting or restarting.  When I wrap a try/finally
around my call to Tk's mainloop, I can see that when I restart Fvwm,
my finally clause gets tripped after Tk's mainloop is terminated.

    RJR> So perhaps a good idea would be a packet type of M_FVWM_EXIT
    RJR> (or just M_EXIT, or similar) that is sent to all modules

This might be a cleaner (and better documented) way of signalling
termination to the modules.  Although the current approach seems to
work for me, this addition probably doesn't burden Fvwm much.

-Barry

---

From: Dan Astoorian <[email-masked]>
Date: Fri, 14 Mar 1997 18:47:56 -0500

>>>>>> "RJR" == Randy J Ray <[email-masked]> writes:
[...]
>work for me, this addition probably doesn't burden Fvwm much.

On the other hand, if a module is relying on a special message to tell
it when fvwm is going away, it's not going to do The Right Thing if fvwm
doesn't exit cleanly (eg. if the X server shuts down, killing fvwm
before it can send the M_EXITs to its children).

Modules should be able to detect and deal with their pipes being closed
unexpectedly; adding a redundant (but less reliable) mechanism to signal
that fvwm is terminating would make it *less* clean.

--                          People shouldn't think that it's better to have
Dan Astoorian               loved and lost than never loved at all.  It's
http://www.utopia.csas.com  not, it's better to have loved and won.  All
[email-masked]       the other options really suck.    --Dan Redican
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: "Barry A. Warsaw" <[email-masked]>
Date: Fri, 14 Mar 1997 19:08:30 -0500

>>>>> "DA" == Dan Astoorian <[email-masked]> writes:

    DA> Modules should be able to detect and deal with their pipes
    DA> being closed unexpectedly; adding a redundant (but less
    DA> reliable) mechanism to signal that fvwm is terminating would
    DA> make it *less* clean.

You might have a point there.  AFAIK, Python/Tk can handle the current
arrangement just fine.

---

From: "Randy J. Ray" <[email-masked]>
Date: Fri, 14 Mar 1997 17:28:11 -0700

> that fvwm is terminating would make it *less* clean.

I disagree. Strongly, even. This is like saying that since a general UNIX
application cannot trap SIGKILL, why bother trapping HUP or any others.

If the X server goes away in a non-clean fashion, taking Fvwm down without
adequate time for a clean exit, then any running modules are likely to nosedive
as well, no matter what event handlers, signal handlers, etc. are set up.
That's just an unfortunate factor of programming in this environment. In such
an instance, a module is likely to get a HUP or KILL before it detects the
broken pipe anyway. But if fvwm is going to exit cleanly, then the modules
should have the same opportunity.

Do you suggest that people just not use event-driven toolkits? Leave Perl/Tk
aside for a moment, no Xt or Xaw? Since I've been writing a WinList-clone as
a sample script for the X11::Fvwm stuff, I've been looking at the source for
FvwmWinList pretty closely. To avoid using a toolkit, the authors had to
re-invent the button, adding a whole C module to the application, when Xt
could have simplified the code.

No, there should be some means by which an application that is X-event-driven
can also handle the fvwm interface. Now, if someone can suggest a good place
to put a regular test for the fd validity, that's different. Then it's more
feasible. But all the callbacks that are currently in my app are bound to
specific events-- availability of data on the input-fd from fvwm, a specific
packet type, or an X event handled by Tk.

Perhaps a test that takes place after every successful packet read? This could
be added into whatever routine is called upon receipt of data from fvwm.

Randy

---

From: Jason L Tibbitts III <[email-masked]>
Date: 14 Mar 1997 21:10:13 -0600

>>>>> "DA" == Dan Astoorian <[email-masked]> writes:

DA> Modules should be able to detect and deal with their pipes being closed
DA> unexpectedly; adding a redundant (but less reliable) mechanism to
DA> signal that fvwm is terminating would make it *less* clean.

OK, but consider for a bit the possibility that you might like to tell a
module go away without quitting FVWM.  It seems better to ask the module to
go away, rather than just yanking its input stream.  An EXIT packet
wouldn't necessarily tell the module that FVWM is going away, but only that
the module should go away.

I'm assuming, of course, that there isn't already an EXIT packet.  It's
been a while since I hacked on FVWM modules.

Of course, modules should still properly handle FVWM croaking anyway.

 - J<

---

From: "Randy J. Ray" <[email-masked]>
Date: Fri, 14 Mar 1997 20:23:03 -0700

> Of course, modules should still properly handle FVWM croaking anyway.

I've gotten around my earlier problems by looking for an error return from
sysread (the perl equivalent of C's read(), since perl's read is actually
build on the buffered-IO layer) and (for now) not even using select() to poll
my fd's. I am also inquiring on the perl list if there are any known bugs with
select on HP's (luckily, we have a guy from HP support on the list).

So I am handling exits all right, and will probably add in a special handler
category in my perl module to allow programmers to respond to the exit. But
I still think M_EXIT would be a good idea:

Packet:
word 1	:-	Window ID      \
word 2	:-	Fvwm Frame ID   > These three are standard
word 3	:-	Fvwm window ID /
word 4	:-	Restart: 0 if Fvwm is really quitting, 1 if Fvwm is doing a
			Restart (as is denoted by the flag to Done() in fvwm.c)

Randy

---

From: Dan Astoorian <djast@utopia>
Date: Sat, 15 Mar 1997 16:14:44 -0500

>application cannot trap SIGKILL, why bother trapping HUP or any others.

Nonsense.  SIGHUP serves one purpose--usually that of telling a process
that it should try to shut itself down cleanly--and SIGKILL serves a
completely different purpose--that of forcing a process to exit whether
it wants to or not.

Closing the file descriptor does not force the module to exit any more
than sending an M_EXIT would--either event is a request to clean up and
exit.  (For that matter, a module is free to continue running and do
anything it wants to--except receive information from and send commands
to fvwm.)

>as well, no matter what event handlers, signal handlers, etc. are set up.

However, there are even already a few modules out there which are not
themselves X11 programs--consider FvwmAudio and FvwmAuto, for example.
The X server could go away and they'd never know the difference if they
weren't checking for EOF on the pipe to fvwm.

>should have the same opportunity.

The modules *do* have the same opportunity--they can detect EOF on their
pipe and exit cleanly.  But it's very much possible that whatever caused
fvwm to exit abruptly--whether it was an X server crash or something
else--*didn't* kill the modules, and in such a case the modules could
wind up in a CPU loop trying to read a defunct file descriptor.

In order to receive the M_EXIT packet, a program first needs to read the
pipe from fvwm; if it knows enough to read from the pipe, surely it can
detect an EOF condition on it?

> the module should go away.

That's pretty much what fvwm is saying when it closes its end of the pipe.
For example, fvwm does this when doing a Restart--it's telling the
modules to exit, even though fvwm itself keeps going.

For reference, the documentation (docs/modules.tex) says:
| Special attention is paid to the status of the pipe. If Fvwm gets a read
| error on a module-to-fvwm  pipe, then it assumes that the module is
| terminating, and all communication with the module is terminated.
| Similarly, if a module gets a read error on an fvwm-to-module pipe, then
| it should assume that fvwm is terminating, and it should gracefully shut
| down.  All modules should also allow themselves to be shut down via the
| Delete Window protocol for X-11.