Okay, this is why busy modules using synchronized messages can run into a deadlock with fvwm: take for example FvwmEvent with the sync'ed M_DESTROY_WINDOW message.
1) When a lot of things are going on on the desktop (many X events are coming in), fvwm handles all of them and puts the module messages into the module queues (PositiveWrite()). 2) Now that we have a long message queue for our module, an event arrives that triggers a synchronized module message. In the case of FvwmEvent, a dying window triggers a M_DESTROY_WINDOW message. 3) The new message is added to the queue via PositiveWrite(). Afterwards, fvwm looks at the packet type and sees that the module requested synchronized transmission and goes into the part dealing with synchronization. 4) Next, "FlushMessageQueue(module)" is called. This function spits the data into the module pipe at full speed - and because the queue is so large, it pipe gets finally full and the next write() call returns EWOULDBLOCK or EAGAIN. 5) FlushMessageQueue stops writing data and simply returns. Result: fvwm entered the sync'ed code branch and waits for the unlock message from the module. But because the pipe is full, the M_DESTROY_WINDOW message that needed synchronization in the first place is never sent. The module simply waits for further input that never comes since fvwm waits for the unlock message. What do we do about this? Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
