Remove obsolete second wakeup_paused

[madroach]

It was introduced in d5822af.
If I understand correctly this was done to prevent calling select
without timeout while there were pending paused promises.

Since now we explicitely check for this condition and call select with
zero timeout (should_block_waiting_for_io). This extra wakeup_paused
seems to be obsolete.

Maybe in Lwt.pause it should also be documented that Lwt.pause () needs to be used 2 / 3 times to enforce completion of a whole main loop iteration. The current documentation talks about the 'next "tick"'? #916

[raphael-proust]

If I remember correctly, the backend-agnostic/unix-free pause mechanism was added in order to support js_of_ocaml. Does anyone know if the double waking of paused promise is necessary for compatibility (as in, to produce a more similar scheduling) as on js-of-ocaml? I doubt it because I doubt we have enough control about the scheduling of promises on different js backends that we can even dream about scheduling compatibility.

Ping @vouillon @hhugo

[raphael-proust]

With this change, the behaviour of pause and yield becomes identical. I think that we should remove the code for yield and simply define yield as an alias for pause.

We could even remove yield altogether because it has been deprecated. But maybe it's worth waiting one or two releases before we remove it to smooth out the transition.

[raphael-proust]

There needs to be an entry in the CHANGES file. I can add it later before merging if you prefer.

[raphael-proust]

(I don't know how to use github very well and I mostly had comments not related to the chunks anyway, so I left comments but apparently they don't count as a review but I think this does?)

[madroach]

While preparing a CHANGES entry I found this:

Lwt_main.yield and Lwt_unix.yield are deprecated in favor of the generic Lwt.pause, and Lwt_unix.auto_yield is deprecated in favor of the new Lwt_unix.auto_pause. Currently, Lwt_main.run resolves paused promises more frequently than yielded promises; the difference is unintended but existing applications could unintentionally depend on it. (#855, #858, Favonia)

Now I'm wondering in what way existing applications could depend on this behaviour?
I suspect they can't.

[raphael-proust]

Now I'm wondering in what way existing applications could depend on this behaviour?
I suspect they can't.

Well for example, in your case (#916) you had to use three calls to pause where one call to yield sufficed. There could be an application that depends on this the same way that you do, but maybe does not know about it. As you pointed out it's not well documented/specified.

[madroach]

Yes, resolving paused promises more often may break stuff intending to wait for one whole iteration. But resolving less often? No I don't think so.

[madroach]

added a CHANGES entry

[raphael-proust]

Hi,

I've added a commit to your branch. We can roll it back or amend it or something. It's more of a proposal/suggestion than anything.

The idea behind it is that pause is now equivalent to yield (modulo the fact that yielded promises are resolved after which paused promises are. (So choose [yield () >|= incr a; pause () >|= incr b; yield () >|= a;] will actually have an intermediate state where a=2 and b=1.) But I think this difference is

• undocumented
• not something anyone should rely on in any way
• not something anyone is likely to rely on in any way

So the commit just makes Lwt_unix.yield = Lwt.pause. And then it can eliminate some unneeded code.

Let me know what you think.

[madroach]

I think this is sensible. There is indeed no relevant difference between yield and pause.

github's UI is confisuin and Idk how to use reviews so I'm just dismissing this