Blocking of SIGINT (ctrl-c), general feedback

[Nico Schottelius]

John Goerzen [Mon, Apr 19, 2010 at 11:34:32AM -0500]:
> Nico Schottelius wrote:
> > Good morning offliners,
> > 
> > I've been using offlineimap for some time and it mostly does
> > a good job.
> > 
> > Though there's one thing that annoys me quite much, the handling
> > of Ctrl-C: For some time offlineimap does not only ignore ctrl-c,
> > but also leaves the shell in question in a state, where ctrl-c
> > does not work anymore, also not for programs started after it.
> 
> I'm confused about that statement.  If OfflineIMAP ignores Ctrl-C, how
> does it leave the shell in a questionable state after pressing it?

Well, it ignore ctrl-c, finishes and _after_ that the shell (zsh/urxt)
does not repsond to ctrl-c anymore.

I know that this used to work a long time ago (about 2 years?), but stopped
working when I switched from Debian to Ubuntu at that time.
Currently I can reproduce this behaviour also in arch linux (6.2.0-1).

When I run this script, it is not interruptable anymore after the first
run of offlineimap:

http://git.schottelius.org/?p=nsbin;a=blob;f=hole_mails;h=649f181fdc970cca390b9cdc9d8202596883dcca;hb=HEAD

> I imagine you're using a curses UI to produce this behavior.

Exactly.

> I'm not
> really surprised; after all, if you interrupt a program hard, then you
> can expect your terminal to be messed up.  Pressing q might produce
> better results for you.

Sure, if ncurses does not restore the previous defaults, that's true.
But offlineimap is not and cannot be aborted here with ctrl-c.

> > A different issue I've is synchronising a new IMAP folder
> > with 160.000 messages in it, which has already taken about
> > 6 hours in which only 100.000 messages where retrieved.
> 
> There are probably several things at work there.  OfflineIMAP is not
> optimized for that work case, and will be requesting those messages
> individually. 

So would it be possible to add some code to handle large folders to
offlineimap?

> Whether or not the IMAP server can handle such requests
> quickly is an open question.

True. The only thing I looked at was the systems state.

> Also, OfflineIMAP's local UID cache is not really optimized for it
> either.  You can try disabling fsync in your ~/.offlineimaprc for a
> performance benefit at the expense of potential incorrectness if your
> system experiences a crash in the middle of a sync.

Hmm, did not have the feeling that it's the hd/fs-cache which limited
tha transfer rate, but can monitor that next time.

Is there anything I can do to contribute to a faster offlineimap?

My aim would be to use offlineimap together with sup and probably
replace the current folder structure of mutt, but this can only be
done if both mirroring some thousands of mails works fastly and also
sup's performance increases...

Cheers,

Nico

-- 
New PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0
Please resign, if you signed 9885188C or 8D0E27A4.

Currently moving *.schottelius.org to http://www.nico.schottelius.org/ ...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/offlineimap-project/attachments/20100419/0dde3b46/attachment-0001.sig>