@velartrill i did not know about them! you never stop learning :)

@bonifartius yeah everyone seems to prefer sockets these days, to the point that it's almost all you see used

@velartrill i can't think of a reason why _i_ would need the message queues, but that doesn't mean anything :D

buuuut https://github.com/torvalds/linux/blob/master/include/uapi/linux/msg.h
the pid seems to be included! at least from what i see with my limited kernel knowledge :)

@bonifartius msg_lrpid is unfortunately useless because there's no way to use it to reliably associate every message with a PID :(

@velartrill aah, just read that it's the last pid who used the syscall

@bonifartius yeah, i don't know *why* they even record that, it's so useless. posix mqs do away with it entirely

@bonifartius i use message queues for IPC in a couple of my projects, including the instance control bus for my social media server, but what i can do with it is kind of limited because you have to rely completely on kernel-level access control

@bonifartius tho come to think of it it might be possible to do something like, the client process creates its own receiver queue, then sends a message to the server with that queue's ID, then the server could use msgctl(IPC_STAT) to get the receiver queue creator pid and uid

that would be pretty minimally nasty for a system that involves two-way communication, tho doesn't solve the problem for fire-and-forget messages alas

@velartrill
> tho come to think of it it might be possible to do something like, the client process creates its own receiver queue, then sends a message to the server with that queue's ID, then the server could use msgctl(IPC_STAT) to get the receiver queue creator pid and uid

from my limited knowledge it sounds like a good solution

> that would be pretty minimally nasty for a system that involves two-way communication, tho doesn't solve the problem for fire-and-forget messages alas

maybe just open seperate queues for them too? shouldn't cost that much and you may just wrap that into a helper function

@bonifartius yeah, you could do it that way, it's just kind of a hack

then again i have no right to talk the last IPC bus i wrote involved a mix of shared memory, sysv mqs, and real-time signals

@velartrill
> yeah, you could do it that way, it's just kind of a hack

so many of the supposedly "good" libraries for these things are just hacks stacked above each other :)