Archive of RubyForge sup-talk mailing list
 help / color / mirror / Atom feed
From: ezyang@MIT.EDU (Edward Z. Yang)
Subject: [sup-talk] Sup is hanging
Date: Fri, 05 Jun 2009 01:08:10 -0400	[thread overview]
Message-ID: <1244177820-sup-6051@javelin> (raw)
In-Reply-To: <1244130722-sup-4496@entry>

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


  reply	other threads:[~2009-06-05  5:08 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-03 17:39 Edward Z. Yang
2009-06-03 18:11 ` William Morgan
2009-06-03 18:26   ` Edward Z. Yang
2009-06-03 18:21 ` Edward Z. Yang
2009-06-03 18:45   ` Edward Z. Yang
2009-06-03 21:36   ` William Morgan
2009-06-03 21:48     ` Edward Z. Yang
2009-06-04  2:11       ` William Morgan
2009-06-03 22:00     ` [sup-talk] Sup is hangingy Edward Z. Yang
2009-06-04  1:26       ` Edward Z. Yang
2009-06-04  1:53         ` [sup-talk] Sup is hangingyy Edward Z. Yang
2009-06-04 16:09           ` [sup-talk] Sup is hanging William Morgan
2009-06-05  5:08             ` Edward Z. Yang [this message]
2009-06-05 13:23               ` William Morgan
     [not found]               ` <1244227108-sup-3123@cabinet>
2009-06-05 21:47                 ` Edward Z. Yang
2009-06-06  6:20                   ` Edward Z. Yang
2009-06-08 18:09                     ` William Morgan
2009-06-04  2:12       ` [sup-talk] Sup is hangingy William Morgan
2009-06-04  2:13       ` William Morgan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1244177820-sup-6051@javelin \
    --to=ezyang@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox