> On Fri, 14 Mar 1997 18:21:13 EST, "Barry A. Warsaw" writes:
> >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.
>
> 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.
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
--
===============================================================================
Randy J. Ray -- U S WEST Technologies IAD/CSS/DPDS Phone: (303)595-2869
Denver, CO rjray_at_uswest.com
"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 majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Fri Mar 14 1997 - 18:28:36 GMT