From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.devel Subject: Re: MS-Windows build broken in Fmake_network_process Date: Sat, 27 Mar 2010 14:56:13 +0100 Message-ID: References: <83634jglab.fsf@gnu.org> <831vf7ge57.fsf@gnu.org> <83y6hfeyzw.fsf@gnu.org> <83vdcig87f.fsf@gnu.org> <83r5n6f8s7.fsf@gnu.org> <83ociaf296.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1269698924 30006 80.91.229.12 (27 Mar 2010 14:08:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 27 Mar 2010 14:08:44 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 27 15:08:40 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 1NvWgp-0001C0-Hv for ged-emacs-devel@m.gmane.org; Sat, 27 Mar 2010 15:08:39 +0100 Original-Received: from localhost ([127.0.0.1]:50260 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NvWgo-00038y-VO for ged-emacs-devel@m.gmane.org; Sat, 27 Mar 2010 10:08:38 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NvWUs-0005UL-Tg for emacs-devel@gnu.org; Sat, 27 Mar 2010 09:56:18 -0400 Original-Received: from [140.186.70.92] (port=34646 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NvWUr-0005Te-LH for emacs-devel@gnu.org; Sat, 27 Mar 2010 09:56:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NvWUq-00039O-Hu for emacs-devel@gnu.org; Sat, 27 Mar 2010 09:56:17 -0400 Original-Received: from dial-181203.pool.broadband44.net ([212.46.181.203]:58771 helo=ix) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NvWUo-00038y-Gj; Sat, 27 Mar 2010 09:56:14 -0400 Original-Received: from helmut by ix with local (Exim 4.69) (envelope-from ) id 1NvWUn-00029p-6H; Sat, 27 Mar 2010 14:56:13 +0100 In-Reply-To: <83ociaf296.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 27 Mar 2010 14:11:17 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Mailman-Approved-At: Sat, 27 Mar 2010 10:04:34 -0400 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:122764 Archived-At: * Eli Zaretskii [2010-03-27 12:11+0100] writes: >> 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. But the code in wait_reading_process_output does use getsockopt inside #ifdef GNU_LINUX and a very odd way to extract some error code in the #else branch. Despite that it's also inside an #ifdef NON_BLOCKING_CONNECT. Note that src/s/ms-w32.h defines BROKEN_NON_BLOCKING_CONNECT. In summary that code path is hardly ever executed. > 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? a) Trust the Windows API documentation for getsockopt. Judging from the documentation alone there's little reason to assume that it wouldn't work in a similar way as on Unix. or b) reproduce the scenario described in bug 5173 on Windows to see if connect returns EINTR and getsockopt works. > 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. Writing code as described in the API documentation seems reasonable to me. I also had asked some questions regarding this code in http://lists.gnu.org/archive/html/emacs-devel/2009-12/msg00337.html but nobody answered. Then I filed bug 5173 that was ignored too. When bug 5723 popped up I asked the same question again, bug again the maintainers didn't know the answer but they decided to put some code into trunk for testing. I don't see what's wrong with this approach. Helmut