Sending UDP on macOS fails

Ecosystem
, , ,
1

Hi,

I’m trying to send an UDP packet using Async:

(* corebuild -pkg async sendudp.native *)
open Core.Std
open Async.Std

let buf = "hello world\n"
  |> Iobuf.of_string
  |> Iobuf.read_only

let addr = Unix.Inet_addr.of_string "127.0.0.1"

let socket_addr = Unix.Socket.Address.Inet.create addr ~port:2115

let def =
  let s = Socket.create Socket.Type.udp in
  let open Or_error.Monad_infix in
  let send = Udp.sendto () |> Or_error.ok_exn in
  send (Socket.fd s) buf socket_addr

let () = 
  Command.async
    ~summary:"herp"
    Command.Spec.(empty)
    (fun () -> def)
  |> Command.run

When I run it, I get this error:

Uncaught exception:

  (unimplemented Bigstring.sendto_nonblocking_no_sigpipe)

Raised at file "src/error.ml" (inlined), line 7, characters 14-30
Called from file "src/or_error.ml", line 67, characters 17-32
Called from file "sendudp.ml", line 15, characters 13-45

So when I look at core 113.33.00+4.03 I see when I recompile it these errors:

- src/bigstring_stubs.c:727:2: warning: "MSG_NOSIGNAL not defined; bigstring_send{,msg}_noblocking_no_sigpipe not implemented" [-W#warnings]
- #warning "MSG_NOSIGNAL not defined; bigstring_send{,msg}_noblocking_no_sigpipe not implemented"
-  ^
- src/bigstring_stubs.c:728:2: warning: "Try compiling on Linux?" [-W#warnings]
- #warning "Try compiling on Linux?"
-  ^
- 2 warnings generated.

So it seems like I can’t sendto an Iobuf.t on macOS?

1 Like
2

As far as I know, Core_async doesn’t support anything beyond linux.
You’d better stick with Lwt if you are doing crossplatform programming.

3

This is not true.

Async is generally portable across multiple architectures, and internally, we use Async seriously within a JavaScript environment. It’s true that we don’t routinely test on OSX, though I use it there myself fairly regularly for personal projects. I think UDP on OS X is less used (I’ve never tried it myself, for example), so it’s less surprising for there to be an issue there.

I think that the best way to get the attention of the Async devs on this issue would be to post an issue on the Async project on github:

1 Like
4

Also, as this is pretty clearly a bug, a PR (again, via Github) is always welcome!

1 Like
5

Async maintainer here. Like Ron said, Core and Async are built to support a variety of platforms. They are by no means built or intended to be Linux-only. However, the majority of the development and testing of Core and Async do occur on Linux, so there are a few places where we don’t have as good support for OS X or the BSDs as one would like. In those situations, we considers those bugs and are very welcoming of patches.

Before I started at Jane Street, I definitely contributed several patches to fix build and conditional compilation issues on FreeBSD. Even after I joined, I and the other maintainers have merged patches from outside contributors along similar lines. The best place to bring up these issues or to request that we merge some patches is on the GitHub issues page of the relevant repository. We watch those issue pages more closely than we watch this forum. (I had to sign up for an account just to respond to this.)

Now, to your issue. It probably just boils down to OS X not defining MSG_NOSIGNAL in the headers that we’re including. The check that’s performed to define JSC_MSG_NOSIGNAL, which makes these function definitions available, depends on MSG_NOSIGNAL being defined. So either there’s another header that needs to be included if compilation occurs on OS X, or some alternative flag needs to be used to get similar behavior to MSG_NOSIGNAL. It might take some digging, but this should ultimately be a simple code change to make, which we’d be happy to merge.

1 Like
6

Ok, thanks. I was suspecting this was a bug but wasn’t 100% sure, since it could’ve been that I messed up my build environment and it was somehow affecting the code.

It looks like macOS equivalent of MSG_NOSIGNAL is SO_NOSIGPIPE, I’ll try to contribute a fix when I get to it.

True. I am not quite sure how to approach it yet, because the sendto_nonblocking_no_sigpipe functions are defined in a Linux-specific file. I believe the way to go is to move it to some Unix-specific file and then conditionally compile the right flag in.

7

Here’s the PR. I don’t know how the contribution process to Jane Street libraries goes, so I’ve just submitted it as I saw fit.

I should mention that it would be nice if there was a tool which would set up a Jane Street development environment because I had to pin quite a number of packages when they were failing to build. Thanks to OPAM 2.0 for allowing local switches, so that did not mess up my other switches!

8

Try adding GitHub - janestreet/opam-repository: Opam repository for the development version of Jane Street packages as an opam remote. It has the working set of development Core packages that are regularly updated.

1 Like