Hi William,
I tickled the bug and took a more careful look at the message that had
triggered it, and noticed that it was an auto-generated commit message
that was really long. So one possible stop-gap would be just to detect
if a message is long and disable quoting if that was the case (a long
message would be, say, one over 100KB). There is also a possibility
that the commit message had some pathological backtracking built into
it.
Excerpts from William Morgan's message of Thu Jun 04 12:09:40 -0400 2009:
> Redwood::Index#load_entry_for_id (22%)
> Redwood::IMAP#load_message (25%)
> Redwood::Message#message_to_chunks (16.5%)
> Redwood::IMAP#load_header (14%)
> Redwood::Index#sync_message (13%)
Ok, so this isn't the same spread as when I managed to make Sup hang,
so this isn't quite the same.
> Now that's all CPU stuff. There might be memory blowup issues. If
> nothing else, Sup leaks memory over time, but fixing that involves the
> getting into the hellish world of Ruby<->C land or the even more hellish
> internals of MRI, so I've been loathe to start down that path.
Sup memory leakage has not been a problem; Sup will hang on a poll
asynchronously (as in, UI is still responsive, but I get no more
new messages) often enough that I have to quit and start sup up again.
> None of this answers the original question of why all Ruby threads block
> when Sup waits for a response from IMAP. Since I'm pretty sure the IMAP
> libraries are all Ruby (why they're so slow!), and that core Ruby IO
> should be nonblocking, this might be an interpreter bug. Are you able to
> pinpoint what part of MRI is blocking?
Not yet. I don't know Ruby threads well enough to know how to get more
fine-grained information on thread mutex/blocking interaction.
To summarize:
1. If I thrash message_to_chunks() with a very long message, I cause
sup to hang.
* If this case is only caused by long messages, implement a hueristic
to prevent quoting from happening to long messages.
* If there is something specific about the message that causes massive
back-tracking, fix the regex.
In either case, message_to_chunks() should not block the rest of the
interface (although if we fix either or the two sub-points, this
may not be a noticeable problem).
2. If an IMAP connection hangs, it occasionally causes all of Sup to
block (this is rare, and comes from a pathological IMAP server. I
think the ops administering the naughty IMAP server fixed it, so
I am no longer seeing this hang).
3. Under less pathological cases, an IMAP connection can hang, and
asynchronously blocks any further polling from taking place, resulting
in no new messages. This happens commonly for me.
Cheers,
Edward
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
