* commit 3286715e509f8ca70efd674d59f6c58e16fdf95a
@ 2011-01-04 1:16 James Cloos
2011-01-11 19:43 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: James Cloos @ 2011-01-04 1:16 UTC (permalink / raw)
To: ding
That change does not avoid a doubled call to SELECT when the first
finds newer data than gnus last saw, but instead guarantees a second
SELECT in all cases:
read(0, "40884 SELECT \"news@lists.oasis-open.org\"\r\n", 4096) = 42
read(0, "40885 SELECT \"news@lists.oasis-open.org\"\r\n40886 UID FETCH 1:* FLAGS\r\n", 4096) = 69
read(0, "40932 SELECT \"pwg-announce@pwg.org\"\r\n", 4096) = 37
read(0, "40933 SELECT \"pwg-announce@pwg.org\"\r\n", 4096) = 37
read(0, "40934 UID FETCH 1:* FLAGS\r\n", 4096) = 27
read(0, "40935 SELECT \"python-announce-list@python.org\"\r\n", 4096) = 48
read(0, "40936 SELECT \"python-announce-list@python.org\"\r\n", 4096) = 48
read(0, "40937 UID FETCH 1:* FLAGS\r\n", 4096) = 27
etc.
Also, as of commit 70fb02450c4c5ccd9b the M-g case seems to wobble
between issuing the second SELECT and its UID FETCH in a single write(2)
vs each in its own write(2). I have not detected any difference which
would explain when it is a single write(2) vs two write(2)s....
-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: commit 3286715e509f8ca70efd674d59f6c58e16fdf95a
2011-01-04 1:16 commit 3286715e509f8ca70efd674d59f6c58e16fdf95a James Cloos
@ 2011-01-11 19:43 ` Lars Magne Ingebrigtsen
2011-01-11 22:49 ` James Cloos
0 siblings, 1 reply; 6+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-01-11 19:43 UTC (permalink / raw)
To: ding
James Cloos <cloos@jhcloos.com> writes:
> That change does not avoid a doubled call to SELECT when the first
> finds newer data than gnus last saw, but instead guarantees a second
> SELECT in all cases:
[...]
> read(0, "40932 SELECT \"pwg-announce@pwg.org\"\r\n", 4096) = 37
> read(0, "40933 SELECT \"pwg-announce@pwg.org\"\r\n", 4096) = 37
> read(0, "40934 UID FETCH 1:* FLAGS\r\n", 4096) = 27
I'm unable to reproduce this. Are you just doing an `M-g' on the group?
--
(domestic pets only, the antidote for overdose, milk.)
larsi@gnus.org * Lars Magne Ingebrigtsen
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: commit 3286715e509f8ca70efd674d59f6c58e16fdf95a
2011-01-11 19:43 ` Lars Magne Ingebrigtsen
@ 2011-01-11 22:49 ` James Cloos
2011-01-22 19:39 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: James Cloos @ 2011-01-11 22:49 UTC (permalink / raw)
To: ding
>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
LMI> James Cloos <cloos@jhcloos.com> writes:
>> That change does not avoid a doubled call to SELECT when the first
>> finds newer data than gnus last saw, but instead guarantees a second
>> SELECT in all cases:
LMI> [...]
>> read(0, "40932 SELECT \"pwg-announce@pwg.org\"\r\n", 4096) = 37
>> read(0, "40933 SELECT \"pwg-announce@pwg.org\"\r\n", 4096) = 37
>> read(0, "40934 UID FETCH 1:* FLAGS\r\n", 4096) = 27
LMI> I'm unable to reproduce this. Are you just doing an `M-g' on the group?
Yes, that was from just an M-g. (Recorded by strace(8)ing the imapd process.)
-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: commit 3286715e509f8ca70efd674d59f6c58e16fdf95a
2011-01-11 22:49 ` James Cloos
@ 2011-01-22 19:39 ` Lars Ingebrigtsen
2011-01-22 21:47 ` James Cloos
0 siblings, 1 reply; 6+ messages in thread
From: Lars Ingebrigtsen @ 2011-01-22 19:39 UTC (permalink / raw)
To: ding
James Cloos <cloos@jhcloos.com> writes:
> Yes, that was from just an M-g. (Recorded by strace(8)ing the imapd process.)
I think I see why this may be happening.
If the group isn't known before, then an `M-g' will first select the
group to get some basic info on the group.
Then the "rescan the group completely" code will issue a SELECT again --
not to select the group, but to get some other bits that it needs to do
the complete rescan.
So I don't think this is a bug.
--
(domestic pets only, the antidote for overdose, milk.)
larsi@gnus.org * Lars Magne Ingebrigtsen
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: commit 3286715e509f8ca70efd674d59f6c58e16fdf95a
2011-01-22 19:39 ` Lars Ingebrigtsen
@ 2011-01-22 21:47 ` James Cloos
2011-01-22 21:54 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: James Cloos @ 2011-01-22 21:47 UTC (permalink / raw)
To: ding
Lars Ingebrigtsen <larsi@gnus.org> writes:
> James Cloos <cloos@jhcloos.com> writes:
>
>> Yes, that was from just an M-g. (Recorded by strace(8)ing the imapd process.)
>
> I think I see why this may be happening.
>
> If the group isn't known before, then an `M-g' will first select the
> group to get some basic info on the group.
The group is known, though. At the very least it was EXAMINEd by g
and often it has been read before in that gnus session.
> Then the "rescan the group completely" code will issue a SELECT again --
> not to select the group, but to get some other bits that it needs to do
> the complete rescan.
> So I don't think this is a bug.
Too bad that it cannot get all of the info SELECT provides in the first go. :^/
-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: commit 3286715e509f8ca70efd674d59f6c58e16fdf95a
2011-01-22 21:47 ` James Cloos
@ 2011-01-22 21:54 ` Lars Ingebrigtsen
0 siblings, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2011-01-22 21:54 UTC (permalink / raw)
To: ding
James Cloos <cloos@jhcloos.com> writes:
> The group is known, though. At the very least it was EXAMINEd by g
> and often it has been read before in that gnus session.
Hm. Could you edebug through `nnimap-request-group' and see why it
SELECTs twice?
I think it's the (assoc group nnimap-current-infos) that returns nil for
you, for some reason:
(deffoo nnimap-request-group (group &optional server dont-check info)
(let ((result (nnimap-possibly-change-group
;; Don't SELECT the group if we're going to select it
;; later, anyway.
(if (and (not dont-check)
(assoc group nnimap-current-infos))
nil
group)
server))
articles active marks high low)
> Too bad that it cannot get all of the info SELECT provides in the first go. :^/
Too difficult. :-)
`M-g' is kinda special in that it is a manual function that's not
supposed to be very fast, anyway, so...
--
(domestic pets only, the antidote for overdose, milk.)
larsi@gnus.org * Lars Magne Ingebrigtsen
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-01-22 21:54 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-04 1:16 commit 3286715e509f8ca70efd674d59f6c58e16fdf95a James Cloos
2011-01-11 19:43 ` Lars Magne Ingebrigtsen
2011-01-11 22:49 ` James Cloos
2011-01-22 19:39 ` Lars Ingebrigtsen
2011-01-22 21:47 ` James Cloos
2011-01-22 21:54 ` Lars Ingebrigtsen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).