From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: MS-Windows build broken in Fmake_network_process Date: Sat, 27 Mar 2010 14:11:17 +0300 Message-ID: <83ociaf296.fsf@gnu.org> References: <83634jglab.fsf@gnu.org> <831vf7ge57.fsf@gnu.org> <83y6hfeyzw.fsf@gnu.org> <83vdcig87f.fsf@gnu.org> <83r5n6f8s7.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1269688374 31391 80.91.229.12 (27 Mar 2010 11:12:54 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 27 Mar 2010 11:12:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 27 12:12:50 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1NvTwg-0002u4-1h for ged-emacs-devel@m.gmane.org; Sat, 27 Mar 2010 12:12:50 +0100 Original-Received: from localhost ([127.0.0.1]:41933 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NvTwe-0003An-Bv for ged-emacs-devel@m.gmane.org; Sat, 27 Mar 2010 07:12:48 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NvTw8-0002yN-Rj for emacs-devel@gnu.org; Sat, 27 Mar 2010 07:12:16 -0400 Original-Received: from [140.186.70.92] (port=36017 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NvTw7-0002xk-CP for emacs-devel@gnu.org; Sat, 27 Mar 2010 07:12:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NvTw6-0000zm-Is for emacs-devel@gnu.org; Sat, 27 Mar 2010 07:12:15 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:45860) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NvTw6-0000zc-CH for emacs-devel@gnu.org; Sat, 27 Mar 2010 07:12:14 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0KZX00A00TEE6F00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Sat, 27 Mar 2010 14:11:14 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.176.135]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KZX008O7TQPTY40@a-mtaout23.012.net.il>; Sat, 27 Mar 2010 14:11:14 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:122760 Archived-At: > From: Helmut Eller > Date: Sat, 27 Mar 2010 11:09:17 +0100 > > > I don't argue about this code's correctness or necessity on Posix > > systems. I accept your and others' expert knowledge about that. What > > I'm saying is that this code is unneeded and possibly inappropriate on > > Windows, where most of the system calls and mechanisms involved in > > this issue work in an entirely different way under the hood. > > Therefore, I submit that this code should have never been installed > > unconditionally, at least not without discussing its applicability and > > implications on Windows. > > You seem to think that adding lots of #ifdefs is a good solution No, I don't. I think it's an ugly solution which should only be taken as a last resort. That is why I asked you to provide an alternative solution that didn't use getsockopt, like the one we already have in wait_reading_process_output. I hoped that such an alternative solution would avoid the #ifdef. Failing that, unless we have on board an expert on Windows sockets, or could find one, who could explain how this affects Windows, what else can we do except #ifdef this code away? I do think that it is a bad idea to apply code that was written on very specific assumptions about the underlying low-level system behavior, to platforms whose behavior is fundamentally different. > The code in question is not executed unconditionally. It's inside an > if(errno==EINTR). If Windows' connect doesn't return EINTR the code is > still correct and simpler than adding #ifdefs. I didn't say Windows will never generate EINTR at that point. I simply don't know enough about the subject to analyze all the possible flows which could lead to that point, and make sure none of them will ever generate EINTR. The original code did have this portion, which was also run on Windows: if (xerrno == EINTR) goto retry_connect;