ZMQ_INPROC(7)

πŸ’Œ ZMQ_INPROC(7) β€” the 0MQ manual, but make it make sense

okay bestie, sit down, hydrate, because we're talking about zmq_inproc β€” the 0MQ local in-process (inter-thread) communication transport. it's giving messages sliding between your own threads, no network, no drama ✨


🌸 NAME 🌸

zmq_inproc β€” the 0MQ local in-process (inter-thread) communication transport. yes that's the whole name, she's lowkey humble πŸ’…


✨ SYNOPSIS ✨

The in-process transport passes messages via memory directly between threads sharing a single 0MQ context. like, straight up memory-to-memory. no packets were harmed πŸ¦‹

Note β€” No I/O threads are involved in passing messages using the inproc transport. Therefore, if you are using a 0MQ context for in-process messaging only you can initialise the context with zero I/O threads. See zmq_init(3) for details.

not me telling you that you can run with zero I/O threads if inproc is all you do. iconic efficiency fr fr πŸ’€βœ¨


πŸŽ€ ADDRESSING πŸŽ€

A 0MQ endpoint is a string made of transport:// followed by an address. The transport says which underlying protocol to use. The address says which transport-specific address to connect to.

For the in-process transport, the transport is inproc, and the meaning of the address part is defined right below. keep reading bestie πŸ‘‘

🫢 Assigning a local address to a socket

When you assign a local address to a socket using zmq_bind() with the inproc transport, the endpoint shall be interpreted as an arbitrary string identifying the name to create. The name must be unique within the 0MQ context associated with the socket, and may be up to 256 characters in length. No other restrictions are placed on the format of the name.

so like... call it whatever you want, just don't be out here copying somebody else's name in the same context. 256 chars max, that's the vibe check πŸ’…

🌈 Connecting a socket

When you connect a socket to a peer address using zmq_connect() with the inproc transport, the endpoint shall be interpreted as an arbitrary string identifying the name to connect to. Before version 4.0 the name must have been previously created by assigning it to at least one socket within the same 0MQ context as the socket being connected. Since version 4.0 the order of zmq_bind() and zmq_connect() does not matter, just like for the tcp transport type.

pre-4.0 you had to bind first or it was a whole situation 😭 post-4.0? free yourself. order is whatever, she's flexible now. main character energy πŸŽ€


πŸ’– EXAMPLES πŸ’–

Assigning a local address to a socket.

//  Assign the in-process name "#1"
rc = zmq_bind(socket, "inproc://#1");
assert (rc == 0);
//  Assign the in-process name "my-endpoint"
rc = zmq_bind(socket, "inproc://my-endpoint");
assert (rc == 0);

Connecting a socket.

//  Connect to the in-process name "#1"
rc = zmq_connect(socket, "inproc://#1");
assert (rc == 0);
//  Connect to the in-process name "my-endpoint"
rc = zmq_connect(socket, "inproc://my-endpoint");
assert (rc == 0);

see how #1 and my-endpoint match up on both sides? that's the whole trick. bind one side, connect the other, slay πŸ¦‹


πŸ‘‘ SEE ALSO πŸ‘‘

go read those too, they're all part of the same friend group πŸ’œ


🧚 AUTHORS 🧚

This page was written by the 0MQ community. To make a change please read the 0MQ Contribution Policy at http://www.zeromq.org/docs:contributing.

community-written, community-loved, periodt 🌸


and that's the whole page bestie!! this was 0MQ 4.3.5, dated 10/09/2023 β€” she's a little vintage but she still eats πŸ’…βœ¨πŸ«Ά

πŸ“¦ where this page comes from