From: Ted Zlatanov <tzz@lifelogs.com>
To: emacs-devel@gnu.org
Subject: Re: Nebulous streaming/point bug
Date: Tue, 22 Nov 2011 12:33:42 -0500 [thread overview]
Message-ID: <87ehx0giyx.fsf@lifelogs.com> (raw)
In-Reply-To: m3vcr1klf3.fsf@stories.gnus.org
On Thu, 03 Nov 2011 21:20:32 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Based on your patch I think it's a GnuTLS bug. They are up to 3.x now,
>> which makes it harder: do we keep supporting the 2.x series or do we
>> start using 3.x, which will be harder to obtain because it's new,
>> especially for the W32 build? I'd rather not support both and just move
>> to 3.x, which has a fairly compatible API, and see if the bug is still
>> there. What do you think?
LMI> I think we should support both. I really want normal Emacs 24.1 users
LMI> to have encrypted network connections by default.
Hrm. OK, I'll do what I can, but I don't think I'll have the time to do
this work in the next few months.
>> Obviously all this would happen after the release; for now I think it's
>> best to use your patch and note it's temporary.
LMI> If people think the approach is halfway sane, I can clean up the patch
LMI> and apply, but I'd love to have some feedback first.
LMI> To recap:
LMI> Some versions of libgnutls do not seem to work well with select. That
LMI> is, they don't say that there's anything there even though there is.
LMI> So the idle loop, which does a select on all the file descriptors don't
LMI> get (all) the data from gnutls sockets. My "fix" is to loop through all
LMI> the channels, see whether they are gnutls sockets, and then calling
LMI> emacs_gnutls_record_check_pending on each one.
LMI> Since this is done in the idle loop, it's typically done once every
LMI> second or so, apparently. So the performance hit should be negligible.
LMI> The loop looks like this:
LMI> for (channel = 0; channel < MAXDESC; ++channel)
LMI> if (! NILP (chan_process[channel]))
LMI> ... do stuff
LMI> But it's an ugly hack.
LMI> So: Add the hack or not?
I'm in favor, if the GnuTLS devs agree. They should know best if this
is a bug or we're using it badly.
Ted
prev parent reply other threads:[~2011-11-22 17:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-12 23:00 Nebulous streaming/point bug Lars Magne Ingebrigtsen
2011-10-12 23:08 ` Lars Magne Ingebrigtsen
2011-10-12 23:14 ` Lars Magne Ingebrigtsen
2011-10-12 23:18 ` Lars Magne Ingebrigtsen
2011-10-12 23:44 ` Lars Magne Ingebrigtsen
2011-10-13 0:34 ` Lars Magne Ingebrigtsen
2011-10-13 1:04 ` Lars Magne Ingebrigtsen
2011-10-13 12:56 ` Ted Zlatanov
2011-10-27 22:12 ` Ted Zlatanov
2011-11-03 20:20 ` Lars Magne Ingebrigtsen
2011-11-22 17:33 ` Ted Zlatanov [this message]
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=87ehx0giyx.fsf@lifelogs.com \
--to=tzz@lifelogs.com \
--cc=emacs-devel@gnu.org \
/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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.