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

Cleanup Channel/Socket #101

Open
6 of 7 tasks
rbx opened this issue Oct 12, 2018 · 0 comments
Open
6 of 7 tasks

Cleanup Channel/Socket #101

rbx opened this issue Oct 12, 2018 · 0 comments
Assignees
Labels
feature New feature or request
Milestone

Comments

@rbx
Copy link
Member

rbx commented Oct 12, 2018

  • get rid of unused interfaces (no deprecation needed, since these are unused (at least not known to us)):

    • get rid of SetSendTimeout/GetSendTimeout/SetReceiveTimeout/GetReceiveTimeout (at least from the general interface). Values set by these FairMQSocket methods are currently used only inside each transport - they are transport details. The actual transfer timeouts are controlled by the user via transfer calls, e.g.: Receive(FairMQMessagePtr& msgVec, const int timeout = 0). It is up to the transport how to implement it these. A general timeout value currently has no meaning in the user-facing API.
    • get rid of GetOption/SetOption and replace with specific API, such as SetLinger/GetLinger. This is less error-prone and more type-safe. Currently these interfaces are only used internally in FairMQDevice for high watermark and kernel transfer size settings.
    • get rid of general GetSocket interface - it returns internal socket representation, which should not be visible from the interface API.
  • rename SendAsync/ReceiveAsync to more clear TrySend/TryReceive Remove SendAsync/ReceiveAsync, instead Send/Receive with a timeout of 0 can be used (since these are used, this will require a deprecation warning iteration). This is already the case in the transport API, but not yet in Channel API.

  • move Bind/Connect/Attach implementations from device class to channel class.

  • introduce (experimental?) value-based move-only fair::mq::Message in parallel to existing FairMQMessage. As a consequence this will require new overloads for send/receive and serialization APIs.

Anything else?

@rbx rbx added this to the v1.4 milestone Oct 12, 2018
@rbx rbx self-assigned this Oct 12, 2018
@rbx rbx added the feature New feature or request label Oct 12, 2018
@rbx rbx modified the milestones: v1.4, v1.5 Apr 17, 2019
@rbx rbx mentioned this issue Nov 20, 2020
@dennisklein dennisklein modified the milestones: v1.5, v1.6 Aug 12, 2022
@dennisklein dennisklein modified the milestones: v1.6, next Jun 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants