msgctl(), msgsnd(), msgrcv(), etc...

msgctl(), msgsnd(), msgrcv(), etc...

Post by Stephane Charet » Thu, 26 Sep 2002 15:04:34



First, I want to thank Andrew Gierth et al. for the FAQ that so far
answered many of my "newbie" questions.

The only remaining question I have at this point has to do with
message queues.  I'm looking for an example of message queues,
possibly even somewhere within the RH Linux 6.x, 7.x?  I've ordered
Richard Stevens volume #2, "IPC", but that wont get here for a few
more days...

Are message queues something that get used frequently, or are they
deprecated?  I'm always hearing about unix domain sockets, pipes, and
local TCP/UDP, but until I began looking into this particular issue
I'm trying to solve, I'd never before encountered the UNIX message
queues.

While I'm at it -- the problem I'm trying to solve is to have a daemon
running that collects information from many other processes.  These
other processes open a known queue for write access, and fairly
frequently spew information, such as status updates, debug
information, etc.  The daemon process would be started first, and have
the queue open for read access, thus collecting all the information
and logging it to the appropriate places.  Am I on the right track
with using message queues, or is there something more obvious?  All of
this is happening within the same box.

TIA,

Stephane Charette

 
 
 

msgctl(), msgsnd(), msgrcv(), etc...

Post by Marc Rochkin » Fri, 27 Sep 2002 00:10:08


Some info:

UNIX has two completely different message-queue APIs: System V IPC (the ones
you are asking about), and POSIX messages (mq_*). The former are very widely
implemented (they are in all the major UNIX versions, in Linux, and in
FreeBSD), whereas the latter, part of the POSIX real-time options, are not.

The System V IPC calls were not included in POSIX until the most recent
standard, 1003.1-2001, although the POSIX messages have been included (as an
option) since 1993. Both have always been in the Single UNIX Specification
since version 1, and now SUS v. 3 and IEEE 1003.1-2001 are one and the same
document, so all is tied up neatly.

In the SUS (and in POSIX2001), the POSIX messaging is still an option,
whereas the System V IPC messaging is mandatory. So a system that claims
conformance to SUS1 (also known as UNIX 95) or SUS2 (also known as UNIX 98)
is REQUIRED to include the System V IPC calls (semaphores and shared memory,
too).

You can rely on the System V IPC messaging to be present in UNIX forever.
It's not deprecated. The only problem with using the POSIX messaging is that
it may not be implemented on systems you care about, such as FreeBSD and
Linux.

As far as efficiency goes, it depends on the implementation. I compared the
two on Solaris, where both are implemented, and the times were about the
same for what I was doing. (I would guess that underneath they are using the
same basic kernel mechanisms.) The sematics are different, however, and you
may find one or the other better for your application.

The Stevens book compares the features of both and gives examples.

It seems to me that messages are OK for your application. One BIG advantage
of sockets, however, is that they naturally go between machines, and using
them gives you the freedom to re-architect your system for that later if you
want.

--Marc

 
 
 

msgctl(), msgsnd(), msgrcv(), etc...

Post by Casper H.S. Di » Fri, 27 Sep 2002 04:07:12



>As far as efficiency goes, it depends on the implementation. I compared the
>two on Solaris, where both are implemented, and the times were about the
>same for what I was doing. (I would guess that underneath they are using the
>same basic kernel mechanisms.) The sematics are different, however, and you
>may find one or the other better for your application.

The mechanisms used are actually completely different; the SysV stuff
is completely implemented in the kernel; the POSIX stuff is implemented
in the filesystem and using plain other system calls like mmap().

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

msgctl(), msgsnd(), msgrcv(), etc...

Post by Marc Rochkin » Fri, 27 Sep 2002 05:30:11


Quote:> The mechanisms used are actually completely different; the SysV stuff
> is completely implemented in the kernel; the POSIX stuff is implemented
> in the filesystem and using plain other system calls like mmap().

> Casper

Very interesting... the original motivation of the POSIX.4 group in coming
up with their own API was performance issues in the Sys V stuff.
(Gallmeister, "POSIX.4," O'Reilly, p. 94).

Is the implementation of the real-time POSIX API in Solaris suitable for
critical (i.e., time-challenged) real-time?

--Marc

 
 
 

msgctl(), msgsnd(), msgrcv(), etc...

Post by Dragan Cvetkovi » Fri, 27 Sep 2002 05:45:47




> >As far as efficiency goes, it depends on the implementation. I compared the
> >two on Solaris, where both are implemented, and the times were about the
> >same for what I was doing. (I would guess that underneath they are using the
> >same basic kernel mechanisms.) The sematics are different, however, and you
> >may find one or the other better for your application.

> The mechanisms used are actually completely different; the SysV stuff
> is completely implemented in the kernel; the POSIX stuff is implemented
> in the filesystem and using plain other system calls like mmap().

Casper is right (as usually, of course). I remember once playing with
mq_open() with large number of messages with large size and it took ages to
initialise. I guess that OS was doing some equivalent of mkfile + mmap.

Bye, Dragan

--
Dragan Cvetkovic,

To be or not to be is true. G. Boole      No it isn't.  L. E. J. Brouwer

 
 
 

msgctl(), msgsnd(), msgrcv(), etc...

Post by Sony E Anton » Fri, 27 Sep 2002 10:56:11




>>As far as efficiency goes, it depends on the implementation. I compared the
>>two on Solaris, where both are implemented, and the times were about the
>>same for what I was doing. (I would guess that underneath they are using the
>>same basic kernel mechanisms.) The sematics are different, however, and you
>>may find one or the other better for your application.

> The mechanisms used are actually completely different; the SysV stuff
> is completely implemented in the kernel; the POSIX stuff is implemented
> in the filesystem and using plain other system calls like mmap().

Is that true for semaphores too ( SysV vs POSIX ) ?
--sony
Quote:

> Casper

 
 
 

1. msgget() and msgsnd() and msgctl() !!!!

Hi!

I have created a message queue with msgget (IPC_PRIVATE, IPC_CREAT).
I now need to be able to fork() a process from my main program (which
called msgget), and let the fork()ed process send messages to the
its parent.  

I also need to be able to spawn N processes, and let them all be
able to put messages into another queue.

How do I use msgctl to set the permissions of the message queue?  I need
to be able to have one queue available for writing by 1 process to
its parent, and I need to have one queue available for writing
by N processes to their common parent.

Help!  I know that I use msgsnd(), but it's coming back with
permission errors!  Help!  Help!

Thanks a lot!!!!!!!!!!!!!!!!!!!!

Matt

2. Linux META-FAQ

3. msgsnd(), msgrcv() and removing obsolete messages

4. Linux Frequently Asked Questions with Answers (Part 6 of 6)

5. msgsnd, msgrcv ????

6. Netscape4.51 on BSD3.2 and KDE

7. msgrcv/msgsnd error

8. Tar barfs on filname > 14 char.

9. IPC SMP race: msgrcv may not return before msgsnd is done

10. Help .. msgctl, msgget etc

11. msgctl

12. SUSv2 msgctl compliance

13. msgget & msgctl