Hello,
It is easy to write some fvwm code to reproduce a
[FVWM][FlushMessageQueue]: <<ERROR>> Failed to write descriptor
error.
Just do so that:
- fvwm grab the server
- fvwm "FlushMessageQueue"
- a module is locked at some place (server is grabbed)
--> The error
So, fine, we should not FlushMessageQueue when we grab the server
(e.g., in a non opaque move).
Unfortunately, it seems that we can have a FlushMessageQueue errors
with a fastly reapeted sequence:
- fvwm grab the server
- fvwm do somting
- fvwm ungrab the server
- fvwm "FlushMessageQueue"
I will be interested by any comments on the following (non conservative)
solution:
In FlushMessageQueue (module_interface.c), do not select with
moduleTimeout but with a very short timeout, if select fail
do not kill the module, just return (the msg queue will be flushed later!).
Patch attached. Maybe this should be allowed only in certain
condition. Also, the module may be killed if FlushMessageQueue
*always* fail for a "long time".
Regards, Olivier
--- module_interface.c.orig 2005-01-16 07:09:38.000000000 +0100
+++ module_interface.c 2005-01-16 07:10:34.000000000 +0100
@@ -1651,7 +1651,6 @@
void FlushMessageQueue(int module)
{
- extern int moduleTimeout;
mqueue_object_type *obj;
char *dptr;
int a;
@@ -1689,8 +1688,8 @@
{
/* Wait until the pipe accepts further
* input */
- timeout.tv_sec = moduleTimeout;
- timeout.tv_usec = 0;
+ timeout.tv_sec = 0;
+ timeout.tv_usec = 10;
FD_ZERO(&writeSet);
FD_SET(channel, &writeSet);
rc = fvwmSelect(
@@ -1707,6 +1706,7 @@
}
if (!FD_ISSET(channel, &writeSet))
{
+#if 0
char *name;
name = get_pipe_name(module);
@@ -1721,6 +1721,7 @@
name, rc, isTerminated ?
'Y' : 'N');
KillModule(module);
+#endif
return;
}
