QBIPCC.H(3)

✨ NAME ✨

qbipcc.h β€” the Client IPC API, aka your bestie's side of the phone call πŸ’–


🌸 SYNOPSIS 🌸

#include <qb/qbipcc.h>

πŸ¦‹ DESCRIPTION πŸ¦‹

πŸ’… Lifecycle of an IPC connection

okay so listen. An IPC connection is literally a whole relationship arc, and here's how it goes.

You make the connection to the server with qb_ipcc_connect(). That function is the one that slides into the server's DMs and requests that channels get created for communication. Iconic. Then when you're done? To disconnect, the client either just exits, or it executes qb_ipcc_disconnect(). That's it. That's the whole situationship. 🫢

⭐ Synchronous communication

The function qb_ipcc_sendv_recv() sends an iovector request and receives a response. Send, then receive. Very "you text, they text back." No cap. ✨

πŸ”₯ Asynchronous requests from the client

  • The function qb_ipcc_sendv() sends an iovector request.
  • The function qb_ipcc_send() sends an message buffer request.

(And yes bestie, "an message" is exactly what the original says β€” we do not edit the sacred text πŸ’€)

πŸŽ€ Asynchronous events from the server

The qb_ipcc_event_recv() function receives an out-of-band asynchronous message. These asynchronous messages are queued up, and they can provide very high out-of-band performance β€” like, the messages are literally waiting in line for you, it's giving VIP section.

And to figure out when to call qb_ipcc_event_recv()? You use the qb_ipcc_fd_get() call to obtain a file descriptor, and then you plug that fd into the poll() or select() system calls. That's your little notification bell πŸ””. iykyk.


🌈 SEE ALSO 🌈

Go read these next, bestie, they're all part of the same lore:


Copyright (C) 2010-2020 Red Hat, Inc.

okay that's the whole page, you ate it, you understood it, you're literally the main character of IPC now πŸ’œ

and for the cute sign-off: this whole thing lives under LIBQB, dated 2025-09-16, and its little name is QBIPCC.H(3). periodt. πŸ’…πŸŒΈ

πŸ“¦ where this page comes from