Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix branch-0.34 forward merge conflicts #74

Merged

Conversation

pentschev
Copy link
Member

@pentschev pentschev commented Aug 7, 2023

Closes #71

bdice and others added 4 commits July 26, 2023 13:11
This PR adds appropriate pinnings for `gtest` and `gmock` in `libucxx-tests`.

Authors:
  - Bradley Dice (https://github.com/bdice)

Approvers:
  - Peter Andreas Entschev (https://github.com/pentschev)
  - Ray Douglass (https://github.com/raydouglass)

URL: rapidsai#66
)

This PR introduces various fixes:

* Fix destruction of `ucxx::RequestTagMulti`, which after moving to inheriting from `ucxx::Request`, using `setStatus()` was missing, thus causing the `ucxx::RequestTagMulti` to never cleanup its inflight request status. Calling `setStatus()` instead of writing the `_status` attribute directly resolves this.
* The status of `ucxx::RequestTagMulti` was until now always `UCS_INPROGRESS` or `UCS_OK` after completing. This is not right but there is no good way to combine the statuses of all underlying requests. Therefore we now set the status of the first failing request as the final status instead of `UCS_OK` if at least one of the requests failed. The user can still check each underlying's request status if granular information is required.
* Since `ucxx::RequestTagMulti` now inherits from `ucxx::Request`, the latter's trace logging for creation/destruction are sufficient, thus removing the redundant trace logs is appropriate.
* Add lifetime trace logs for `ucxx::BufferRequest`.
* Execute user-defined callback within the scope fo `ucxx::Request::setStatus()` to prevent accidental reordering mistakes, as the callback needs to always execute after the status is set, because the callback itself might make use of that information. Additionally it will prevent missing execution of the callback should `setStatus()` be called elsewhere in the future.
* Return `std::shared_ptr<Buffer> in allocateBuffer()` as returning raw pointers may cause leaks, and can be problematic specifically in `ucxx::RequestTagMulti` as the `Buffer*` will not be released unless the user takes ownership and releases it appropriately.
* Introduce mutex in `ucxx::Request` because of potential concurrency issues when running with the progress thread, which a mutex can resolve in `ucxx::Request`. A common case is when `ucxx::Endpoint` is registering an inflight request and `setStatus()` has just begun running, in which case the inflight request will be removed (a no-op as it hasn't been previously registered) and then actually registered, which will cause the `ucxx::Request` to never cleanup.

Authors:
  - Peter Andreas Entschev (https://github.com/pentschev)

Approvers:
  - Lawrence Mitchell (https://github.com/wence-)

URL: rapidsai#72
…sai#65)

Implement and use generic callbacks to create endpoints, close endpoints and listeners, and probe tags. By doing this we ensure those don't need to take the UCS spinlock or progress the worker during the application thread, which can be sources of deadlocks.

Authors:
  - Peter Andreas Entschev (https://github.com/pentschev)
  - Lawrence Mitchell (https://github.com/wence-)

Approvers:
  - Lawrence Mitchell (https://github.com/wence-)

URL: rapidsai#65
@pentschev pentschev requested review from a team as code owners August 7, 2023 15:27
@ajschmidt8 ajschmidt8 merged commit 871edb7 into rapidsai:branch-0.34 Aug 7, 2023
16 checks passed
@pentschev pentschev deleted the branch-0.34-merge-branch-0.33 branch October 12, 2023 17:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants