MQ_RECEIVE(2)

πŸ“¦ version 15.1, in freebsd 14.5, freebsd 15.1

πŸ’Œ MQ_RECEIVE(2) β€” bestie's guide to grabbing messages off a queue

okay so this is a page from the System Calls Manual, and no cap, it's the whole entire vibe for pulling a message out of a POSIX message queue. it's REALTIME-coded, it's giving main character IPC, and you're gonna slay it. πŸ’…βœ¨


πŸŽ€ LIBRARY πŸŽ€

POSIX Real-time Library β€” that's librt, and yeah you link it with -lrt. don't forget, i beg of you 😭


🌸 SYNOPSIS 🌸

#include <mqueue.h>

ssize_t
mq_receive(mqd_t mqdes, char *msg_ptr, size_t msg_len,
    unsigned *msg_prio);

ssize_t
mq_timedreceive(mqd_t mqdes, char *msg_ptr, size_t msg_len,
    unsigned *msg_prio, const struct timespec *abs_timeout);

two functions, one job, and the second one has ✨patience✨ built in.


πŸ’– DESCRIPTION πŸ’–

so mq_receive() is the system call that receives the oldest of the highest priority message(s) from the message queue specified by mqdes. like it's not just "a message", it's the message β€” priority first, oldest wins ties. icon behavior tbh πŸ‘‘

but bestie, the size check is real: if the size of the buffer in bytes, specified by the msg_len argument, is less than the mq_msgsize attribute of the message queue, the system call will fail and return an error β€” it does not just truncate, it flat out refuses. so check your buffer, fr fr πŸ™ˆ otherwise, the selected message gets removed from the queue and copied into the buffer that msg_ptr points to. slay.

if the argument msg_prio is not NULL, the priority of the selected message gets stored in the location referenced by msg_prio. free info, no cap πŸ’œ

now the blocking drama: if the specified message queue is empty and O_NONBLOCK is not set in the message queue description associated with mqdes, mq_receive() will block until a message is enqueued on the message queue, or until mq_receive() is interrupted by a signal. so it just sits there. patiently. waiting. it's giving loyal friend energy 🫢

and if more than one thread is waiting to receive a message when a message arrives at an empty queue, and the Priority Scheduling option is supported, then the thread of highest priority that has been waiting the longest gets selected to receive the message. highest priority + longest wait = winner. otherwise? it is unspecified which waiting thread receives the message. literally a coin flip, we don't stan undefined behavior πŸ’€

last bit of the first act: if the specified message queue is empty and O_NONBLOCK is set in the message queue description associated with mqdes, no message will be removed from the queue, and mq_receive() will return an error. nothing happens, nothing leaves the queue, goodbye πŸ¦‹


πŸ¦‹ mq_timedreceive() β€” the same but with a deadline πŸ¦‹

mq_timedreceive() will receive the oldest of the highest priority messages from the message queue specified by mqdes, exactly as described for the mq_receive() system call. same energy, same rules.

However β€” and this is the plot twist β€” if O_NONBLOCK was not specified when the message queue was opened via the mq_open() system call, and no message exists on the queue to satisfy the receive, the wait for such a message will be terminated when the specified timeout expires. bye girl, time's up βŒ›

if O_NONBLOCK is set, this system call is equivalent to mq_receive(). so the whole timeout thing is moot, it just returns immediately like the impatient queen it is.

the timeout expires when the absolute time specified by abs_timeout passes, as measured by the clock on which timeouts are based β€” that is, when the value of that clock equals or exceeds abs_timeout β€” or if the absolute time specified by abs_timeout has already been passed at the time of the call. yes, in the past. retroactively expired. she's already gone 🧚

⭐ heads up bestie: the timeout is based on the CLOCK_REALTIME clock. that's the real one, not the monotonic one. noted.

✨ RETURN VALUES ✨

on the success tip: mq_receive() and mq_timedreceive() return the length of the selected message in bytes, and the message is removed from the queue. so clean. so tidy. we love a definite answer πŸ’–

otherwise (and this is the sad path 😭): no message is removed from the queue, the system call returns a value of -1, and the global variable errno gets set to indicate the error. classic.


πŸ’… ERRORS πŸ’…

the mq_receive() and mq_timedreceive() system calls will fail if:

  • [EAGAIN] β€” the O_NONBLOCK flag is set in the message queue description associated with mqdes, and the specified message queue is empty. nothing to grab, and you said don't wait, so. yeah.
  • [EBADF] β€” the mqdes argument is not a valid message queue descriptor open for reading. wrong door, wrong key, wrong everything πŸ”‘
  • [EMSGSIZE] β€” the specified message buffer size, msg_len, is less than the message size attribute of the message queue. your buffer is too smol, bestie.
  • [EINTR] β€” the mq_receive() or mq_timedreceive() operation was interrupted by a signal. rude, honestly.
  • [EINVAL] β€” the process or thread would have blocked, and the abs_timeout parameter specified a nanoseconds field value less than zero or greater than or equal to 1000 million. do the math, that's 0 ≀ nsec < 1000000000, periodt. πŸ”₯
  • [ETIMEDOUT] β€” the O_NONBLOCK flag was not set when the message queue was opened, but no message arrived on the queue before the specified timeout expired. ghosted by the queue πŸ’€

🌈 SEE ALSO 🌈

mq_open(2), mq_send(2), mq_timedsend(2)

(the whole friend group iykyk 🫢)


πŸ‘‘ STANDARDS πŸ‘‘

the mq_receive() and mq_timedreceive() system calls conform to IEEE Std 1003.1-2004 (β€œPOSIX.1”). certified. official. iconic.


πŸ“ HISTORY πŸ“

support for POSIX message queues first appeared in FreeBSD 7.0. vintage ✨


portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1, 2004 Edition, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 6, Copyright (C) 2001-2004 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group. in the event of any discrepancy between this version and the original IEEE and The Open Group Standard, the original IEEE and The Open Group Standard is the referee document. the original Standard can be obtained online at http://www.opengroup.org/unix/online.html. (okay that's the legal bit, but like, respect it 😌)


πŸŽ€ that's the whole page bestie, go forth and receive your messages β€” this dropped from Debian, dated November 29, 2005, and it ate. mwah πŸ’–
πŸ“¦ where this page comes from