Improve Condition #184

Atry · 2022-03-14T17:40:59Z

Introduced the ADT type ConditionState to replace ?Awaitable<T> in the original implementation, removing HH_FIXME[4110]
Added a Finish state to remove the reference from the child awaitable to the Condition, in case of memory leak
Added wait_for_notification_async and ConditionNotifyee to hide the setState function

Test Plan:

./minitest.sh tests/async/ConditionTest.php

Starting ConditionTest...
--- ConditionTest::runAsync()
-----   ConditionTest::testSucceedFirst()
-----   ConditionTest::testFailFirst()
-----   ConditionTest::testSucceedLater()
-----   ConditionTest::testFailLater()
OK: ConditionTest

facebook-github-bot · 2022-03-14T17:42:00Z

@Atry has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

Atry · 2022-03-14T17:58:42Z

I am not sure about the memory leak part.

Given the following code

async function outer(): Awaitable<void> {
  await wait_for_notification_async(
    async $notifyee ==> {
      concurrent {
        await async {
          await gen_usleep(100);
          $notifyee->trySucceed("fast condition");
        }
        await async {
          await gen_usleep(10000000000);
          $notifyee->trySucceed("slow condition");
        }
      }
    }
  );
}

I want the unfinished "slow condition" not to prevent the outer awaitable from being garbage-collected. Not sure if the current implementation would.

facebook-github-bot · 2022-03-14T18:04:38Z

@Atry has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

facebook-github-bot · 2022-03-14T18:08:19Z

@Atry has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

fredemmott

Requesting changes for small nits and potential for enum classes. Naming TBC.

Will need www performance checks (will comment on internal diffs)

Overall like the removal of the fixme and more explicit states.

fredemmott · 2022-03-15T18:10:24Z

src/_Private/ConditionState.php

+
+namespace HH\Lib\_Private;
+
+use type HH\Lib\Async\Condition;


don't use use type or use function in the HSL outside of tests; we want use namespace HH\Lib\Async;

fredemmott · 2022-03-15T18:13:19Z

src/_Private/ConditionState.php

+  AsyncResult::class,
+  Finished::class,
+)>>
+interface ConditionState<T> {


this API feels a lot like a Promise; would that be a better naming?

this + the interfaces potentially feels like a good use case for enum class - would that make sensehere?

AsyncResult and SyncResult cannot be enum classes because they contain properties. Finished and NotStarted can be turned into enum classes.

fredemmott · 2022-03-15T18:14:55Z

src/async/Condition.php

-      /* HH_FIXME[4110]: Type error revealed by type-safe instanceof feature. See https://fburl.com/instanceof */
-      $this->condition->succeed($result);
+    if (!$this->state->trySucceed($this, $result)) {
+      invariant_violation('Unable to notify Condition twice');


use invariant($condition, $message) instead

fredemmott · 2022-03-15T18:15:05Z

src/async/Condition.php

-      );
-      $this->condition->fail($exception);
+    if (!$this->state->tryFail($this, $exception)) {
+      invariant_violation('Unable to notify Condition twice');


fredemmott · 2022-03-15T18:15:56Z

src/async/Condition.php

+  return $condition->waitForNotificationAsync($notifiers($condition));
+}
+
+interface ConditionNotifyee<-T> {


Similarly feels like a Promise API

I used to name it Promise but the API is different from Promise in either Scala or JavaScript. The current version named it ConditionNotifyee because it is used with the wait_for_notification_async API.

The primary purpose of this interface is to hide the setState function from public API.

fredemmott · 2022-03-15T18:17:57Z

src/async/Condition.php

+): Awaitable<T> {
+  $condition = new Condition();
+  return $condition->waitForNotificationAsync($notifiers($condition));
+}


at a minimum, this needs a similar 'do not use' comment to Async\Poll

AIUI this is a control flow that we specificially do not want to make easier/more straightforward, due to ease of misuse (e.g. it can make it easy to make your request 10% faster by reducing server concurrent requests by 20%, in a way that doesn't show up in request-isolated benchmarking)

fredemmott · 2022-03-15T18:24:59Z

I am not sure about the memory leak part.

Given the following code

async function outer(): Awaitable<void> {
  await wait_for_notification_async(
    async $notifyee ==> {
      concurrent {
        await async {
          await gen_usleep(100);
          $notifyee->trySucceed("fast condition");
        }
        await async {
          await gen_usleep(10000000000);
          $notifyee->trySucceed("slow condition");
        }
      }
    }
  );
}

I want the unfinished "slow condition" not to prevent the outer awaitable from being garbage-collected. Not sure if the current implementation would.

It will not block outer being garbage collected, but the async and concurrent blocks can not complete until the slow condition completes, so they - and anything they depend on - will not complete.

Also an invariant violation will always trigger in this example.

The 'good' uses of awaiting in a loop, and async generators are when everything will eventually be processed, but need to be processed in order. Most uses are inappropriate and should be Vec\map_async or similar.

The 'good' uses of AsyncPoll are when everything passed in will eventually be awaited, but execution is independent - similar to a scheduler without cancellation. In general, 'start but do not finish' or 'ignore everything except the first result' is bad for site health, and not something we want to support in hack - but unfortunately the primitives we need to support the 'good' cases also enable the 'bad' cases.

Atry · 2022-03-15T19:27:23Z

Also an invariant violation will always trigger in this example.

I think it would not trigger an invariant violation because it uses trySucceed instead of succeed.

fredemmott · 2022-03-15T19:33:25Z

Still not sure it's desirable, but if a higher level function is needed, you don't need the notifier to be part of the public API: function can either return or throw, either will be considered resolving the awaitable.

There isn't a need for explicit succeed/fail calls, and probably isn't even a need for explicit catching - the exception will be stored in the awaitable by default.

This would also remove the possibility of weirdness if e.g. people don't return immediately after indicating success or failure

1. Introduce the ADT type ConditionState to replace ?Awaitable<T>, suppressing HH_FIXME[4110] 2. Added a Finish state to remove the reference from the child awaitable to the Condition, in case of memory leak 3. Added wait_for_notification_async and ConditionNotifyee to hide the setState function

Atry · 2022-03-15T19:45:10Z

This PR had multiple purposes. I just split the trySucceed/tryFail changes into #185.

facebook-github-bot · 2022-03-15T20:05:45Z

@Atry has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

facebook-github-bot · 2022-12-02T16:10:05Z

Hi @Atry!

Thank you for your pull request.

We require contributors to sign our Contributor License Agreement, and yours needs attention.

You currently have a record in our system, but the CLA is no longer valid, and will need to be resubmitted.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

Atry requested a review from fredemmott March 14, 2022 17:40

facebook-github-bot added the CLA Signed label Mar 14, 2022

Atry force-pushed the condition branch from f20978e to b372876 Compare March 14, 2022 18:02

Atry force-pushed the condition branch from b372876 to b10bddf Compare March 14, 2022 18:07

Atry requested a review from jano March 14, 2022 18:22

fredemmott suggested changes Mar 15, 2022

View reviewed changes

Atry added 2 commits March 15, 2022 19:38

Add Condition->trySucceed and Condition->tryFail

d643a73

Atry force-pushed the condition branch from b10bddf to cb02cb0 Compare March 15, 2022 19:39

Atry marked this pull request as draft March 15, 2022 20:05

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Improve Condition #184

Improve Condition #184

Atry commented Mar 14, 2022 •

edited

Loading

facebook-github-bot commented Mar 14, 2022

Atry commented Mar 14, 2022 •

edited

Loading

facebook-github-bot commented Mar 14, 2022

facebook-github-bot commented Mar 14, 2022

fredemmott left a comment

fredemmott Mar 15, 2022

fredemmott Mar 15, 2022

Atry Mar 15, 2022 •

edited

Loading

fredemmott Mar 15, 2022

fredemmott Mar 15, 2022

fredemmott Mar 15, 2022

Atry Mar 15, 2022 •

edited

Loading

fredemmott Mar 15, 2022

fredemmott commented Mar 15, 2022

Atry commented Mar 15, 2022

fredemmott commented Mar 15, 2022

Atry commented Mar 15, 2022

facebook-github-bot commented Mar 15, 2022

facebook-github-bot commented Dec 2, 2022

Improve Condition #184

Are you sure you want to change the base?

Improve Condition #184

Conversation

Atry commented Mar 14, 2022 • edited Loading

facebook-github-bot commented Mar 14, 2022

Atry commented Mar 14, 2022 • edited Loading

facebook-github-bot commented Mar 14, 2022

facebook-github-bot commented Mar 14, 2022

fredemmott left a comment

Choose a reason for hiding this comment

fredemmott Mar 15, 2022

Choose a reason for hiding this comment

fredemmott Mar 15, 2022

Choose a reason for hiding this comment

Atry Mar 15, 2022 • edited Loading

Choose a reason for hiding this comment

fredemmott Mar 15, 2022

Choose a reason for hiding this comment

fredemmott Mar 15, 2022

Choose a reason for hiding this comment

fredemmott Mar 15, 2022

Choose a reason for hiding this comment

Atry Mar 15, 2022 • edited Loading

Choose a reason for hiding this comment

fredemmott Mar 15, 2022

Choose a reason for hiding this comment

fredemmott commented Mar 15, 2022

Atry commented Mar 15, 2022

fredemmott commented Mar 15, 2022

Atry commented Mar 15, 2022

facebook-github-bot commented Mar 15, 2022

facebook-github-bot commented Dec 2, 2022

Process

Atry commented Mar 14, 2022 •

edited

Loading

Atry commented Mar 14, 2022 •

edited

Loading

Atry Mar 15, 2022 •

edited

Loading

Atry Mar 15, 2022 •

edited

Loading