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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Oliver Heins wrote:
> Mauricio Fernandez <mfp_AT_acm.org> 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 = Queue.new

Thread.new do
  IXP::Client.new.open('/event') do |f|
    loop do
      events.enq f.read.chomp
    end
  end
end

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

>> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFFGJYGmV9O7RYnKMcRAllBAJ9rhH/N3uIUFsTW+XR1IUK7unyCdwCeO1bk
1e61v/M+YzAKc9tgcY4BsLs=
=D3kJ
-----END PGP SIGNATURE-----
Received on Tue Sep 26 2006 - 04:52:40 UTC