Funny-looking code in imap.el

Funny-looking code in imap.el

[Gaute B Strokkenes]

Having recently switched to using imap over ssl as a mail-source (as
opposed to fetchmail), I have been a bit annoyed at the amount of time
it can take to say `g' now that I have two extra imap-over-ssl
mail-sources.

Looking at imap-ssl-open in imap.el:

	    (while (and (memq (process-status process) '(open run))
			(set-buffer buffer) ;; XXX "blue moon" nntp.el bug
			(goto-char (point-max))
			(forward-line -1)
			(not (imap-parse-greeting)))
	      (accept-process-output process 1)
	      (sit-for 1))

I find the sit-for here rather surprising, though this bit of the
logic is duplicated in the other imap-foo-open functions, so it's
clearly not by mistake.  The elisp manual states that the typical use
of sit-for is to give the user time to read a message; that doesn't
seem useful here.  (The elisp manual also says that sit-for will wait
for the specified amount of time or "until there is input
available"--it's not clear whether this includes output from
subprocesses, but there is already a call to accept-process-output
anyway...)

-- 
Gaute Strokkenes                        http://www.srcf.ucam.org/~gs234/
What a COINCIDENCE!  I'm an authorized ``SNOOTS OF THE STARS'' dealer!!

Re: Funny-looking code in imap.el

[Simon Josefsson]

Gaute B Strokkenes <gs234@cam.ac.uk> writes:

> Having recently switched to using imap over ssl as a mail-source (as
> opposed to fetchmail), I have been a bit annoyed at the amount of time
> it can take to say `g' now that I have two extra imap-over-ssl
> mail-sources.
>
> Looking at imap-ssl-open in imap.el:
>
> 	    (while (and (memq (process-status process) '(open run))
> 			(set-buffer buffer) ;; XXX "blue moon" nntp.el bug
> 			(goto-char (point-max))
> 			(forward-line -1)
> 			(not (imap-parse-greeting)))
> 	      (accept-process-output process 1)
> 	      (sit-for 1))
>
> I find the sit-for here rather surprising, though this bit of the
> logic is duplicated in the other imap-foo-open functions, so it's
> clearly not by mistake.  The elisp manual states that the typical use
> of sit-for is to give the user time to read a message; that doesn't
> seem useful here.  (The elisp manual also says that sit-for will wait
> for the specified amount of time or "until there is input
> available"--it's not clear whether this includes output from
> subprocesses, but there is already a call to accept-process-output
> anyway...)

Is it the sit-for that delay things?  Try removing it.  Perhaps
changing the a-p-o call to (accept-process-output process 0.1) would
speed things up too.

Re: Funny-looking code in imap.el

[Gaute B Strokkenes]

On 14 jul 2003, jas@extundo.com wrote:

> Gaute B Strokkenes <gs234@cam.ac.uk> writes:
>
> Is it the sit-for that delay things?

Yes, that seems to be a big part of it.  Note that I haven't found a
good way to test the speed "scientifically"; this is based purely on
my eyeballing things.

> Try removing it.

That seems to work fine.  Another thing that works is to hit some
harmless key, like `s', right after `g'.  This works because sif-for
will not actually sit if there is pending input.

> Perhaps changing the a-p-o call to (accept-process-output process
> 0.1) would speed things up too.

Perhaps, though I doubt it.  If I understand it correctly, the time
argument to a-p-o is just a timeout; it will return as soon as it gets
some output from the process or when the timeout expires, whichever
comes first.  I suspect it would work just as well to use a really
big value here; the only reason to have a timeout at all seems to be
to avoid busy-looping.

-- 
Gaute Strokkenes                        http://www.srcf.ucam.org/~gs234/
I have nostalgia for the late Sixties!  In 1969 I left my laundry with
 a hippie!!  During an unauthorized Tupperware party it was chopped &
 diced!

Re: Funny-looking code in imap.el

[Gaute B Strokkenes]

On 14 jul 2003, gs234@cam.ac.uk wrote:

>> Gaute B Strokkenes <gs234@cam.ac.uk> writes:
>>
>> Perhaps changing the a-p-o call to (accept-process-output process
>> 0.1) would speed things up too.
>
> Perhaps, though I doubt it.  If I understand it correctly, the time
> argument to a-p-o is just a timeout; it will return as soon as it
> gets some output from the process or when the timeout expires,
> whichever comes first.  I suspect it would work just as well to use
> a really big value here; the only reason to have a timeout at all
> seems to be to avoid busy-looping.

I changed the timeout in the a-p-o call to 666, with no apparent
slowdown or other ill effects.

-- 
Big Gaute                               http://www.srcf.ucam.org/~gs234/
Life is a POPULARITY CONTEST!  I'm REFRESHINGLY CANDID!!

Re: Funny-looking code in imap.el

[Kai Großjohann]

Gaute B Strokkenes <gs234@cam.ac.uk> writes:

> I find the sit-for here rather surprising, though this bit of the
> logic is duplicated in the other imap-foo-open functions, so it's
> clearly not by mistake.

I guess that sleep-for was intended.  Tramp also had sit-for for some
years, before I discovered the problem and changed it to use
sleep-for, instead.

Of course, the sleep-for can also probably be dispended with.

However, the fact that there is a blue moon comment there leads me to
thinking that before trusting any changes we need to wait for the
next blue moon.  Does anyone know when is the next blue moon?  :-)
-- 
~/.signature

Re: Funny-looking code in imap.el

[Simon Josefsson]

Gaute B Strokkenes <gs234@cam.ac.uk> writes:

>> Try removing it.
>
> That seems to work fine.

Does it work to say `(sleep-for 0.1)' instead?

I remember that the reason for the sit-for was to avoid a race
condition where emacs hogs the system and leave no CPU time for
OpenSSL (or other external processes) to run and generate data for
Emacs to read.  This might have been fixed in modern emacsen though.

Re: Funny-looking code in imap.el

[Simon Josefsson]

kai.grossjohann@gmx.net (Kai Großjohann) writes:

> However, the fact that there is a blue moon comment there leads me to
> thinking that before trusting any changes we need to wait for the
> next blue moon.  Does anyone know when is the next blue moon?  :-)

The blue moon comment only relates to the line the comment is on, and
the workaround is still required even for modern Emacs (I tried
removing it a few months ago, but every other week or so there were
weird problems that could be attributed to parsing data in the wrong
buffer, so I reverted my work space to the CVS version).

The sit-for is there for green moon bugs. :-) Redisplay probably isn't
required, just that emacs release the CPU, so sleep-for might work
too, but the safest would probably be to use sit-for but reduce the
delay from 1 second to 0.(0?)1 seconds or so.