On Fri, 14 Mar 1997 17:28:11 MST, "Randy J. Ray" writes:
>
>I disagree. Strongly, even. This is like saying that since a general UNIX
>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.)
>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 nosediv
>e
>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.
>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.
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?
Jason L Tibbitts III <tibbs_at_hpc.uh.edu> writes:
>
> 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.
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.
-- 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
djast_at_utopia.csas.com 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 majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Sat Mar 15 1997 - 15:16:22 GMT