Close file descriptor and DNS resolution in Async

[Mark Li]

1.

  1) For Tcp.Server.create and Tcp.with_connection, I think I need to close underlying file descriptor manually?

  2) Also, for each connection, I have (fun _ r w -> ...). Do I need to close r and then again close w by calling both Reader.close r and Writer.close w respectively?

      I read the .mli file and it says either one will close the underlying file descriptor (Writer.close will also flush before close of course). Is it ok if I just

      do only one of them?

  3) .mli says the difference between "close" and "close_finished" is that "close_finished does not have the side effect of initiating a close". I don't quite understand what 'side effect' means. Does 'close_finished' actually perform close? What does it do exactly?

2. 

  I noticed that DNS resolution is sequentialized by "let sequencer = Throttle.create ~continue_on_error:true ~max_concurrent_jobs:1 in" in unix_syscalls.ml, and it has something to do with thread safety issues with 'winbind'? Can I get more details of this issue? Is anyway to manually bypass this restriction?

Thanks

[Malcolm Matalka]

Mark Li <mar...@gmail.com> writes:

> 1.
> 1) For Tcp.Server.create and Tcp.with_connection, I think I need to close
> underlying file descriptor manually?

From the documentation (emphasis mine):

with_connection ~host ~port f looks up host from a string (using DNS as
needed), connects, then calls f, passing the connected socket and a
reader and writer for it. When the deferred returned by f is determined,
or any exception is thrown, _the socket, reader and writer are closed_.

And for [Tcp.Server.create]:

If the deferred returned by handler is ever determined, or handler
raises an exception, then _reader and writer are closed_.

https://ocaml.janestreet.com/ocaml-core/111.28.00/doc/async/#Std.Tcp

[Mark Li]

I am having file descriptor leak problem. Just want to make sure... Thanks, I am going to check other possible places where file descriptor is not closed.