Re: [Caml-list] How to handle system decencies in Ocaml (like O_ASYNC not implemented in cygwin)

[Adrien Nader <adrien@notk.org>]

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