After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 700850 - Evolution freezes when filtering new email
Evolution freezes when filtering new email
Status: RESOLVED DUPLICATE of bug 704181
Product: evolution-data-server
Classification: Platform
Component: Mailer
3.8.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
evolution[filters]
Depends on:
Blocks:
 
 
Reported: 2013-05-22 16:39 UTC by Claudio Saavedra
Modified: 2013-08-09 15:45 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Claudio Saavedra 2013-05-22 16:39:33 UTC
There is a synchronous call that freezes evo for a few secs every time I receive new email.

Thread 1 (Thread 0x7fc64bdb3a40 (LWP 2959))

  • #0 pthread_cond_wait
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S line 185
  • #1 g_cond_wait
    at gthread-posix.c line 750
  • #2 camel_imapx_job_wait
    at camel-imapx-job.c line 170
  • #3 camel_imapx_job_run
    at camel-imapx-job.c line 219
  • #4 camel_imapx_server_refresh_info
    at camel-imapx-server.c line 7777
  • #5 imapx_refresh_info_sync
    at camel-imapx-folder.c line 758
  • #6 camel_folder_refresh_info_sync
    at camel-folder.c line 4128
  • #7 close_folder
    at camel-filter-driver.c line 1161

This should be using an asynchronous method instead, or at least be done in a different thread if possible.
Comment 1 Claudio Saavedra 2013-05-22 16:47:32 UTC
I think this is evolution-data-server instead.
Comment 2 Claudio Saavedra 2013-05-22 16:49:54 UTC
Basically the whole filter-driver is using sync calls. It seems to me that it should be rewritten to use async calls instead..
Comment 3 Matthew Barnes 2013-05-22 17:40:18 UTC
Yep, known issue.  A major rewrite of filtering is needed when time allows.
Comment 4 Claudio Saavedra 2013-05-23 10:11:25 UTC
This is somehow way more noticeable in F19 (evo 3.8) than it has ever been. Would it be OK if we do a partial rewrite attacking the bottlenecks first? I don't have time to rewrite the whole thing but I could at least replace the sync() calls with async() ones in the most critical paths, if you think this makes sense.
Comment 5 Matthew Barnes 2013-05-23 11:14:34 UTC
Sure, but I can't guarantee when I'll get to it.
Comment 6 André Klapper 2013-08-07 08:19:24 UTC
Claudio: Worked around by / dup of bug 704181?
Comment 7 Milan Crha 2013-08-09 15:45:37 UTC
(In reply to comment #6)
> Claudio: Worked around by / dup of bug 704181?

Definitely.

*** This bug has been marked as a duplicate of bug 704181 ***