From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 2839E7FA5C for ; Sat, 14 May 2016 10:50:18 +0200 (CEST) IronPort-PHdr: 9a23:57caChF8GFMahYMHJR0N7p1GYnF86YWxBRYc798ds5kLTJ75r8iwAkXT6L1XgUPTWs2DsrQf27uQ6furATBIyK3CmU5BWaQEbwUCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYsExnyfTB4Ov7yUtaLyZ/nhqbooNaLP01hv3mUX/BbFF2OtwLft80b08NJC50a7V/3mEZOYPlc3mhyJFiezF7W78a0+4N/oWwL46pyv+YJa6jxfrw5QLpEF3xmdjltvIy4/SXEGEG04XYTTn8Ril4AJgnO7Bj3Wt255i77vep01S3cJsr7QqwuXiyK7qF3RRuugyACYW0X6mbS3+V8lqNWplqHrhBy2caAaY2PNfd4VqXaYdBcQnBOCJUCHxddC5+xOtNcR9EKOvxV+syk/wMD Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=adrien@notk.org; spf=Pass smtp.mailfrom=adrien@notk.org; spf=None smtp.helo=postmaster@nautica.notk.org Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of adrien@notk.org) identity=pra; client-ip=91.121.71.147; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="adrien@notk.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of adrien@notk.org designates 91.121.71.147 as permitted sender) identity=mailfrom; client-ip=91.121.71.147; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="adrien@notk.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@nautica.notk.org) identity=helo; client-ip=91.121.71.147; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="postmaster@nautica.notk.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AoCwAx5jZX/5NHeVtegzdVLlGCcwi4bCaFawKBKDwQAQEBAQEBAQFkJ4ItghYBAQQMFw8BRhAJAhgCAgUTDgICDwUYHQETiEYKlQadHZElMYEBhSSETYc/K4IuBZgnhX6IFgpmgVGMYkWOfDcrgjeBNzqIOAEBAQ X-IPAS-Result: A0AoCwAx5jZX/5NHeVtegzdVLlGCcwi4bCaFawKBKDwQAQEBAQEBAQFkJ4ItghYBAQQMFw8BRhAJAhgCAgUTDgICDwUYHQETiEYKlQadHZElMYEBhSSETYc/K4IuBZgnhX6IFgpmgVGMYkWOfDcrgjeBNzqIOAEBAQ X-IronPort-AV: E=Sophos;i="5.24,617,1454972400"; d="scan'208";a="177797183" Received: from nautica.notk.org ([91.121.71.147]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-GCM-SHA384; 14 May 2016 10:50:17 +0200 Received: by nautica.notk.org (Postfix, from userid 1003) id 3BB14C01B; Sat, 14 May 2016 10:50:16 +0200 (CEST) Date: Sat, 14 May 2016 10:50:16 +0200 From: Adrien Nader To: "Soegtrop, Michael" Cc: =?utf-8?B?SsOpcsO0bWU=?= Benoit , Yaron Minsky , "caml-list@inria.fr" , "ocaml-core@googlegroups.com" Message-ID: <20160514085016.GA11928@notk.org> References: <0F7D3B1B3C4B894D824F5B822E3E5A172CEEEA4D@IRSMSX102.ger.corp.intel.com> <20160506234133.6f1cb28c@nemesis> <0F7D3B1B3C4B894D824F5B822E3E5A172CEEFECE@IRSMSX102.ger.corp.intel.com> <20160507162347.4e61aef7@nemesis> <0F7D3B1B3C4B894D824F5B822E3E5A172CEF0127@IRSMSX102.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0F7D3B1B3C4B894D824F5B822E3E5A172CEF0127@IRSMSX102.ger.corp.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Caml-list] How to handle system decencies in Ocaml (like O_ASYNC not implemented in cygwin) On Mon, May 09, 2016, Soegtrop, Michael wrote: > Dear Jérôme, > > > Maybe I fail to understand what you want to achieve, Cygwin do not report > > an error that OCaml propagate if you use an unsupported flag with open() ? > > the issue is that the O_ASYNC flag isn't even defined in the Cygwin headers, so I can't simply pass an unsupported flag and wait for open to flag it. I could invent a value for the flag, but I am not sure if this is a good idea. So I thought the cleanest way is to raise an exception in the function which returns the value of the flag. > Considering this is cygwin and therefore also Windows, I wouldn't be surprised this isn't supported at all and not merely not exposed. Asynchronous I/O on Windows is profitable only for job safety and psychiatrists. At first, I actually had O_NONBLOCK in mind. After some checking I now see the difference and I really really think you should simply avoid this. Since this flag is basically never used, it's probably worth detailing things a bit. From "man open" on Linux: Enable signal-driven I/O: generate a signal (SIGIO by default, but this can be changed via fcntl(2)) when input or output becomes possible on this file descriptor. This feature is available only for terminals, pseudoterminals, sockets, and (since Linux 2.6) pipes and FIFOs. See fcntl(2) for further details. See also BUGS, below. [...] Currently, it is not possible to enable signal-driven I/O by specifying O_ASYNC when calling open(); use fcntl(2) to enable this flag. And from http://stackoverflow.com/questions/6260114/whats-the-difference-between-async-and-nonblocking-in-unix-socket : O_ASYNC is not used often: - it is extremely difficult to properly handle IO in signal handlers; they are best left as tiny as possible - because signals interrupt the control flow of the program, they 'cost more' to run than standard system calls, such as select(2) or poll(2) - signals provide less information than other calls: they only report one fd ready vs many fds that might be ready. This is going to be useful for serial communications. Clearly. You could even use it for other things like sockets and files but the more work you'll have to do and the less sane it will be. Two sockets? Sure. But nothing more. On Windows you should forget signals besides SIGINT and maybe a couple others. If you end up requiring Cygwin at runtime, you'll never see any user because besides license constraints, you're also adding overhead for syscalls and the likes, which is something one were probably trying to optimize when settling on O_ASYNC (well, and it's probably going to be slow). I'd advise to kill that, preferably with fire. I'm really wondering how many are using that in Core. I actually expect a few because of the serial handling stuff but not more. I would move this to a separate module which is completely optional in Core. Additionally you can also raise an exception when the function is used; maybe it breaks things at runtime but the number of users on Windows who haven't already seen all the warnings signs should be really really low. -- Adrien Nader