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

Replace send and recv flags with a more type-safe API #35

Open
dcbishop opened this issue Apr 6, 2014 · 11 comments
Open

Replace send and recv flags with a more type-safe API #35

dcbishop opened this issue Apr 6, 2014 · 11 comments

Comments

@dcbishop
Copy link
Contributor

dcbishop commented Apr 6, 2014

Currently send/recv functions just take them as an int and there are no defines.

At the very least there should be static definitions. But would probably be better as a proper 'Flag' type (enum?).

@dcbishop
Copy link
Contributor Author

dcbishop commented Apr 6, 2014

Just noticed there are statics (i was greping for NOBLOCK but it got renamed to DONTWAIT in newer ZMQ). But having a proper type would still seem more rustic (rustonic?).

@erickt
Copy link
Owner

erickt commented Apr 7, 2014

Hello @dcbishop. Rust proper is exploring a proper solution to passing around flags like these (see rust-lang/rust#6085 and rust-lang/rust#13072). Once something is decided, I'll switch rust-zmq over to a similar approach.

@jdpage
Copy link

jdpage commented Jun 4, 2015

The bitflags! macro should be able to solve this now.

@rotty
Copy link
Collaborator

rotty commented Oct 22, 2016

@jdpage, @dcbishop Indeed, that area of the API is could do with refinement. As the bitflags! macro looks like the currently established way to achieve that, I hope to come up with a PR making use of that, unless anyone beats me to it (which I'd welcome ;-).

@rotty rotty added this to the 0.9.0 milestone Nov 17, 2016
@rotty
Copy link
Collaborator

rotty commented Nov 17, 2016

This will go in after 0.9, as there seems to be no way to still allow the use of "0" as a flag value using the bitflags crate. I guess for the sake of improved readability, this shouldn't be allowed, either. Thus this requires an API break.

@rotty rotty modified the milestones: 0.10.0, 0.9.0 Nov 17, 2016
@rotty
Copy link
Collaborator

rotty commented Dec 10, 2016

After having pondered about this for a while, I don't think that bitflags is the appropriate solution here. We have different sets of permissible flags, e.g. SNDMORE doesn't make sense with send_multipart() or recv(). Ideally, we want to expose this at the type level, but I'm quite short of a concrete proposal yet, if anyone has ideas about this, I'm all ears!

@rotty
Copy link
Collaborator

rotty commented Dec 11, 2016

My current thinking goes in the direction of eliminating, instead of exposing SNDMORE and DONTWAIT. An initial, rough sketch, and some thoughts can be found in the commits on my wip/flagless branch.

@rotty
Copy link
Collaborator

rotty commented Dec 19, 2016

Besides SNDMORE and DONTWAIT, which I'm still undecided how to deal with, there is also POLLIN, POLLOUT and POLLERR, which should probably be turned into a bitflags type.

@rotty
Copy link
Collaborator

rotty commented Dec 23, 2016

Just a status update: for the poll flags, I now have added a type alias in release/v0.8, see #151, this will be followed up by a switch to bitflags on master. Regarding SNDMORE and DONTWAIT, I've opened an issue to clarify their interaction in zeromq/libzmq#2269. I'll be stalling further "flagless" work waiting for that issue to (hopefully) reach a conclusion.

@BatmanAoD
Copy link

@rotty Any status update? Looks like v0.9 has still not been released.

@rotty rotty modified the milestones: 0.9.0, 0.10.0 Jan 5, 2019
@rotty
Copy link
Collaborator

rotty commented May 27, 2019

The current status in 0.9.0 (and current master) is:

  • The poll flags have been made type-safe, using the PollEvents bitflags type.
  • Embarassingly send and recv still take plain integers.

@rotty rotty changed the title Flags should be exposed. Replace send and recv flags with a more type-safe API May 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants