In the opam repository, the following packages use Lwt_unix.run: aws, cohttp, cowabloga, git, imaplet-lwt, irmin, js_of_ocaml, mirage-xen, obigstore, obus, ocsigenserver, ojs-base, sqlexpr, stog.
Lwt_io.of_string is used by obigstore.
Lwt_sys.window is used by lambda-term.
Also, the Lwt_util module, already removed, is used by redis, ocsigenserver and obigstore.

Given these statistics, maybe we should wait before removing Lwt_unix.run.

We should tell the authors of obigstore, lambda-term and redis about these removal.

cc @diml @avsm @hhugo @samoht @Drup @mfp @zoggy

I learned that Lwt_main.run existed few days ago :p but yes, I am switching to use it in my projects now.

What should be used instead of Lwt_unix.run, then ?

Lwt_main.run

On 10 Feb 2015, at 09:24, Zoggy notifications@github.com wrote:

What should be used instead of Lwt_unix.run, then ?

—
Reply to this email directly or view it on GitHub #107 (comment).

Will this be merged?

Marked these deprecated more clearly. Can't use [@@ocaml.deprecated] because
Lwt still supports 4.01. Also marked Lwt_stream.on_terminate and Lwt_unix.execute_job. Lwt_io.of_string was removed in 6049279.

At least the following packages are still using Lwt_unix.run (some in tests
and examples, but nonetheless):

bistro, cowabloga, csvprovider, dog, git, git-unix, http2https,
imaplet-lwt, iocaml, irmin, irmin-unix, mbr-format,
merge-queues, merge-ropes, message-switch, mirage-git, mirage-irmin,
mirage-profile, mirage-unix, ppx_json_types, riak, sqlexpr, tuntap,
typerex-lldb

Eliom recommends Lwt_unix.run in its documentation
(doc/manual-wiki/server-services.wiki).

At least the following packages are using Lwt_stream.on_terminate:

cohttp

At least the following packages are using Lwt_unix.execute_job:

baardskeerder, lambda-term

No public package is apparently using Lwt_unix.has_wait4 or Lwt_sys.windows,
but there may be private code.

attn @pveber @avsm @rgrinberg @samoht @nv-vn @vasilisp @gregtatcam @andrewray
@talex5 @djs55 @mfp @lefessan

attn @toolslive @metadave

@aantron What should we use instead of Lwt_stream.on_terminate

on_termination of course. I should remember that change.

Lwt_stream.on_termination :)

@aantron I appreciate the ping! I've only used this in the Riak client, which I haven't touched in years.

Thanks for pinging, I've gone ahead and patched that in all projects that were using them.

concerning Lwt_unix.execute_job. I don't see this pull request removing it.
Am I missing something ?

As an aside, I recently worked on the ordma package and needed to implement a new Lwt engine, based on librdmacm's rselect. There were some problems:

• Lwt checks for readability (Lwt_unix.readable) on a Lwt.file_descr on the side using a separate call to poll here, iso going through the engine. This breaks down if the resource represented by this Lwt.file_descr is not a resource that can be poll-ed (in this case an rsocket).
• Lwt.file.descr has some internal state (the state attribute )that cannot be manipulated through the interface. This forced me into using a private copy the definition, and a "cast" via Obj.magic,
  which is really ugly. A typical example is the close call.

Basically, what I'm saying is that there is an API to plug in your own lwt engine, but that it doesn't really work when you actually try to do this (or I wasn't smart enough to figure out how to do this cleanly).

@toolslive This PR didn't originally seek to remove execute_job, but it does now. A commit to do this hasn't been posted yet, because it's too early at this point.

As an aside, ...

Would you be willing to turn this into a separate issue? Copy/paste from here is fine, but reproduction cases and/or patches are also very welcome :)

the aside is continued here

What's the alternative for Lwt_unix.execute_job ?

Thanks. Lwt_unix.run_job is the alternative.

Now using deprecation warnings ([@ocaml.deprecated]). See also #293 ("Semantic versioning; safely breaking Lwt").