Re: [wmii] Re: [ANN] Ruby-IXP 1.0.2

From: Suraj N. Kurapati <>
Date: Mon, 25 Sep 2006 19:52:54 -0700

Hash: SHA1

Oliver Heins wrote:
> Mauricio Fernandez <> writes:
>> On Mon, Sep 25, 2006 at 07:27:13PM +0200, Oliver Heins wrote:
>>> I think the failure is caused by an incompatibility to
>>> Suraj's stability patch. wmiiwm runs rock solid now, but
>>> wmiirc which freezes every now and then. I ran a patched
>>> wmii with branch ruby-ixp[1] for about 48 hours without
>>> restart and did not find a flaw in wmiiwm itself, but had to
>>> restart wmiirc about 40 times.

I too have noticed this wmiirc "freeze" (only twice thus far). Not
sure what's going on... it might just be Ruby-IXP not waking up the
requester thread.

>> I've been using branch-ruby-ixp with plain 3.1 and it's been
>> freezing about twice a day or so. I'll svn update ruby-ixp-svn
>> and apply snk's patches to wmiiwm. Which one(s) are you using
>> exactly, just wmii-3.1_libixp_overload_fix.patch? He's posted
>> many things :)
> Yes, only this patch. It seems to work very nice, as wmii don't
> freezes anymore.
>> That patch changes the semantics of IXP::Client#read quite
>> fundamentally in the case of /event, so it's not that
>> surprising to see wmiirc hang. I'll try to fix this while
>> making it work in both stock 3.1 and the patched version.

Well, the solution to this is a two-stage read, where the first
stage simply reads events, and the second stage processes them.
Something like this:

require 'thread'
events = do'/event') do |f|
    loop do

while evt = events.deq
  # ... do stuff with evt

>> However, I don't consider wmii-3.1_libixp_overload_fix.patch to
>> be the final solution to the problem, since it can cause events
>> to be lost, leading to erratic behavior of the WM.

Due to the design of IXP, event loss is inevitable. For
example, when you open a file for reading and send a request to read
the file, the file's entire contents are sent back to you---in a
single response message.

If you want no data loss for dynamically changing files like /event,
the WM has to do some extra work:

1. When a client requests to open /event for reading, the WM
allocates a buffer for that "session".

2. Every time an event occurs in the WM, the WM enqueues that event
into the buffers of all "sessions".

3. Every time a client requests to read (from an already opened
connection to /event), the WM dequeues an event from the "session"
buffer and sends that to the client.

This way, each client's "session" to /event is buffered, and there
is no data loss. This would even work for that example I gave to
Anselm: (1) a client opens /event for reading, (2) reads it once,
(3) sleeps for three minutes, and (4) reads it again.

But in reality, I think the present limitation is perfectly fine.
Having a two-stage read is "good enough": I haven't
experienced any event loss that way.

>> I'll try to change libixp to use non-blocking IO instead (or to
>> at least give up after a few ms if write(2) would block).

I'll run ruby-ixp in debug mode, log its output, and verify whether
the requester thread is indeed not being woken up.
Version: GnuPG v1.4.2.2 (GNU/Linux)

Received on Tue Sep 26 2006 - 04:52:40 UTC

This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 16:14:25 UTC