From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: network process timeouts Date: Thu, 22 Sep 2016 23:51:21 +0200 Message-ID: References: <87wpi4azuf.fsf@lifelogs.com> <87lgyju495.fsf@lifelogs.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1474581208 28774 195.159.176.226 (22 Sep 2016 21:53:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 22 Sep 2016 21:53:28 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 22 23:53:23 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bnBvf-0005v8-6q for ged-emacs-devel@m.gmane.org; Thu, 22 Sep 2016 23:53:15 +0200 Original-Received: from localhost ([::1]:34936 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bnBvd-0007qv-Fe for ged-emacs-devel@m.gmane.org; Thu, 22 Sep 2016 17:53:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42956) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bnBvX-0007qi-M5 for emacs-devel@gnu.org; Thu, 22 Sep 2016 17:53:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bnBvT-0005BL-J1 for emacs-devel@gnu.org; Thu, 22 Sep 2016 17:53:06 -0400 Original-Received: from hermes.netfonds.no ([80.91.224.195]:36461) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bnBvT-00059F-Ce for emacs-devel@gnu.org; Thu, 22 Sep 2016 17:53:03 -0400 Original-Received: from cm-84.215.1.64.getinternet.no ([84.215.1.64] helo=stories) by hermes.netfonds.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1bnBvP-00075L-1K for emacs-devel@gnu.org; Thu, 22 Sep 2016 23:53:01 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEUIAwTPpGdfIRe2bTml UC8VCwqQOCMEAQIGrAqBAAACYklEQVQ4jXWSQXOjMAyFPbPDcI2A5Nyo4DvY5R7s9Zkm8fbagqsz lw5/f2WTzma3XRGGjD/rPUm2EGL9J5Z8ERz++xBiFHl+v31N+zMhnqEuW/2kTbnPMtWWVWvq+fhT iAv07al4hbYtEHe+KADM246lru3eXotXBccJG3jYVRW0AE0Cpq5eVWG6poFqB5WC4nkfwcHMxaAB nhjADvYVnCI4n4oSikE5KLMjwB66w6mNUv7HDKzA+Q/+WkLJu47wxOVm4xVAj9XhJfM+O0EBu+f3 jKtaP3yG45J/+Jc18yNPIr4iTmpJMxhT39n2X4ivI2Qq8u/Bmta/Bcv/pL6C/Db6L2DhV9xizf9I /BXr3XmeiSaJ9YTIB7u+iNTV6MWZgjWqCgyFF4tvPMaY+BvIGW0IMQ7Ld9ISr4R3z39csI+Kpgh+ 9TSRJJZvkIK2g9RhimO8Hlxanqamdra3A7raJlBFJZJuwuhtBtR2y6i0UkqT41KtsUajIozgUqoW SmXZCkkHy6LS3QArKKfJGmlDcPwMDJZLpSNg5KZ6oMDWm8clWiTQu8eBtfjZPICvcrR3HYVgeQPJ YQPllkEd1SHwdwo3KbsFdbIxwdGsJplA26aEXnbILVrtuNsIjsD6UVrqA7pZlUS2j+CRPTbQ8zS4 EM0lf4JUrVQ2OKO0spo2Kdg8SKHtufNZmf4eaNI4SOT59lJv4NaH4wzW0lyxu2VAYr3CutbEfWxj TyCyXsW+lXljOwbrHeAzCewlbZRa/Bsv8mGxx3xSfBHiDYgZiJQCa2VttA6Uhrie8TMk/ybkCxqP 9jeIXB6hqVOlswAAAABJRU5ErkJggg== In-Reply-To: <87lgyju495.fsf@lifelogs.com> (Ted Zlatanov's message of "Thu, 22 Sep 2016 15:24:38 -0400") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 80.91.224.195 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:207718 Archived-At: Ted Zlatanov writes: > OK... so I shouldn't bother? Or I'm approaching it wrong? I thought > having a timeout in `make-network-process' was the right place for a > global timeout per process, and then the underlying implementation can > choose what to do with that parameter. What would the timeout be for? DNS resolution, socket connection, TLS negotiation or protocol negotiation? I think having a parameter for a timeout for the first three would perhaps be nice if you're programming synchronous network connection stuff (for instance if you're writing something to probe hosts to see whether they're listening to a port), but it's still not quite enough to be generally useful, I think? If you look at, for instance, `url-retrieve-synchronously', it does an asynchronous connection and then loops waiting for it to finish whatever it's doing. Adding a timeout to that function would just involve, well, adding a timeout to that function, and it would not pass that timeout on to the lower levels. So in that use case it's not useful, but perhaps you see other use cases where this is useful? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no