bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#13546: 24.2.92; Error(s) when sending emails


From: Eli Zaretskii
Subject: bug#13546: 24.2.92; Error(s) when sending emails
Date: Fri, 01 Mar 2013 15:58:02 +0200

> From: Ted Zlatanov <tzz@lifelogs.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  13546@debbugs.gnu.org,  
> wxhgmqzgwmuf@spammotel.com
> Gmane-Reply-To-List: yes
> Date: Fri, 01 Mar 2013 06:30:45 -0500
> 
> On Thu, 28 Feb 2013 18:06:56 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 
> 
> EZ> Sebastien, if the latest emacs-24 binary still gives you trouble,
> EZ> please try separate the sub-process and Helm stuff from the email
> EZ> stuff.  That is, start 2 sessions of Emacs: one that uses Helm, but
> EZ> does not use email, the other that uses email, but not Helm (or
> EZ> subprocess-related commands in general).  I'd like to know whether
> EZ> none, one, or both of theses sessions will exhibit some abnormal
> EZ> symptoms after several hours.
> 
> I read through this thread.
> 
> I am not aware of anyone else experiencing this bug on W32 or other
> platforms.

I doubt anyone else who tracks development versions has such an
extreme setup, that puts such a pressure on the infrastructure used in
the w32 Emacs for supporting subprocesses and network connections (the
same infrastructure is used for both types).  As you must have seen in
one of the messages I posted and in the corresponding screencast, Helm
sometimes fires up an async subprocess for every keystroke, then kills
each one of them right away.  Emacs on Windows can only support up to
32 subprocess or up to 64 network connections (each subprocess
requires resources of 2 connections).  So any subtle problems and race
conditions in the related code, that will go unnoticed on more "quiet"
systems, could be exposed by such an enormous resource pressure.  This
is complicated by the fact that Sebastien uses the Cygwin Bash as the
sub-shell, so any subtle problems with controlling, communicating, and
killing such processes from a native w32 application might also come
into play here.

> May I also suggest running without the GnuTLS DLL, which
> will degrade your experience but may give a good differential?

I don't think GnuTLS per se is the problem.  At most, it could be the
fact that emacs_gnutls_pull calls 'select', but I doubt even that.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]