[LCP] Questions regarding message queue
gearon at ieee.org
Fri Aug 3 05:36:22 UTC 2007
Catching up on a backlog of email, I realized that I missed this one...
On Jul 22, 2007, at 11:45 PM, Ludwig Isaac Lim wrote:
> I have 2 questions regarding message queue IPCs:
> 1) What is the standard way of generating a queue id? I
> usually do the following:
> key = ftok(<name of the executable file>,..);
> id = msgget(key,...);
> I can see problems arising when I move the executable
> to another directory.
Actually, while this is theoretically bad, it will often work. The
reason is because the key is generated from the inode of the file.
If you do a simple mv (as opposed to a cp;rm) then the inode won't
change, and hence the value will be the same.
> Does a better alternative exist? Is the code below much
> touch(<name of a temporary file>);
> key = ftok(<name of the temporary file>):
> since "touch" was called prior to ftok, then mostly
> likely, calls to ftok will always be successfull.
Well, there's no "touch" call (unless you use system(3)), but you can
easily use creat(2) or open(2). This approach works just fine.
What you're doing here is essentially registering a service for
clients to connect to. You need some kind of "address" for this
service, otherwise clients won't know how to find you. In the world
of sockets, this is typically done by using a predefined port
number. This is subject to collision, but for well known services
the port number is reserved for that protocol only (eg. port 80 is
You should be safe with a name like:
Anyone colliding with this name is just asking for
difficulties. :-) Besides, the algorithm *can* lead to collisions
anyway - though these are unlikely.
> Supposing somebody deletes the temporary file AFTER the
> message queue has been created. Will it affect the message
Not the queue itself, but now that the file is gone, it will not be
possible for any clients to generate the same key again, even if they
re-create the file (since the inode may be different). Any clients
that are already connected to the shared memory won't notice a problem.
> 2) Is message queue always a better alternative to FIFO?
> The only foreseable problem with message queues if the
> message size larger than msgmax. When is FIFO preferred
> over message queues? It seems that FIFO is much better is
> the message size is very large. Any other opinion?
FIFOs are good for transferring data from one process to another,
particularly large amounts (though if it's big and needs to be
updated, then consider shared memory, and if it's REALLY big then use
mmap). Message queues are a little different:
- Messages have limited size.
- They can be received out of order (controlled with the message type)
- Multiple processes can write to the queue.
- Multiple processes can read from the queue (though this needs to be
In other words, message queues are good for sending messages. :-)
More information about the linuxCprogramming