Very Computer

by **Marc Rochkin** » Wed, 14 May 2003 02:38:42

> response to another thread:
> I didn't mention specifics, because I think most readers of this
> newsgroup will be familiar with these time-worn complaints about
> SysV IPC:

> System V shared memory does not use the filesystem namespace,
> as does almost any other type of unix resource. The traditional
> unix paradigm is that shared resources that are managed by the
> OS are represented as files, e.g. /dev, /proc, etc.

It uses a special ID that can be passed from one process to another and
immediately used to access a message queue, semaphore set, or shared memory
segment, without the overhead of pathname resolution. Very advantageous, as
a process doesn't have to know what objects it will access in advance in
order to get at them efficiently.

A pathname can still be used, with the ftok function.

One could come up with another approach, of course, but this is a deliberate
and well-thought-out design choice, not a "botch."

Quote:> Instead, System V shared memory defines its own funky namespace,
> and provides idiosyncratic tools like ftok() and ipcs to manage
> that namespace. It provides a permissions system that basically
> duplicates filesystem permissions to control access, but you
> can't use chown/chgrp/chmod to manipulate them.

Partially agree, and partially covered by my previous comment.

Quote:
> POSIX shared memory demonstrates that all of these issues can be
> dealt with comfortably within the traditional unix filesystem
> paradigm.

Don't agree:

1. If process A (client) has a POSIX message queue and wants to pass it to
unrelated process B (server) so B can respond, B has a lot of overhead
before it can respond, as all it gets is a path. With Sys V IPC, B can
respond immediately, given only the ID.

2. Does not fit comfortably within the "traditional unix filesystem
paradigm." Pathname is not required to actually exist as a path name, and
does not on some implementations. Also, only paths that begin with a slash a
nd have no other slashes are portable, and, on systems that do use an actual
path, superuser permission may be required for such paths.

It's an attempt at a clean way to do it, but it's "botched."

Quote:
> System V message queues suffer from all of these shortcomings
> with the additional fault that they are not integrated with the
> poll() system call, so there is no convenient way for a single-
> threaded process to block on multiple message queues. (This last
> is also true of POSIX message queues.) Named pipes (FIFOs) don't
> suffer these drawbacks.

Agree. It would be nice if both IPCs allowed you to associate an FD with the
object, for no other reason than to use select or poll.

Ditto for other things you wait on: processes to terminate, signals.

Quote:
> Doubtless more detailed critiques have been published elsewhere,
> but I don't have any links handy.

Well, let me know if you come up with anything else!

--Marc

by **Chuck Dillo** » Wed, 14 May 2003 03:49:05

>>Doubtless more detailed critiques have been published elsewhere,
>>but I don't have any links handy.

> Well, let me know if you come up with anything else!

> --Marc

Generally speaking, I have no significant problem with SysV IPC. The
most vocal critics that I've heard are so because SysV IPC *almost*
fits their problem space but not quite. So you get the "if they'd only
done this or that" response.

Having said that, my biggest gripe about them is that they impose
monolithic architectural characteristics on any system that uses them.
I'm referring to the fact that it's problematic to integrate
disparate SysV IPC based software subsystems from different
vendors/developers on a single box. That's because you can run into
key conflicts since there's no controlled way to manage them and, many
of the kernel limits are system wide so one poorly behaving application
can starve others by consuming available queues, semaphores or shared
memory segments.

I used SysV IPC in the late 80's and early 90's in the context of a
turnkey system where we had control over all software that utilized
them as well as how the kernel was configured. I'd be very leery of
building or using general purpose systems that relied on them.

-- ced

--
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.

by **Casper H.S. Di** » Wed, 14 May 2003 04:08:39

>It uses a special ID that can be passed from one process to another and
>immediately used to access a message queue, semaphore set, or shared memory
>segment, without the overhead of pathname resolution. Very advantageous, as
>a process doesn't have to know what objects it will access in advance in
>order to get at them efficiently.
>A pathname can still be used, with the ftok function.
>One could come up with another approach, of course, but this is a deliberate
>and well-thought-out design choice, not a "botch."

And "unix domain sockets" may be used as an extra counter argument;
they do exist in the pathname namespace and it's that behaviour
(unlink() before bind()) that *is* a botch.

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.

by **Sean Burk** » Wed, 14 May 2003 05:14:28

> > response to another thread:

> > I didn't mention specifics, because I think most readers of this
> > newsgroup will be familiar with these time-worn complaints about
> > SysV IPC:

> > System V shared memory does not use the filesystem namespace,
> > as does almost any other type of unix resource. The traditional
> > unix paradigm is that shared resources that are managed by the
> > OS are represented as files, e.g. /dev, /proc, etc.

> It uses a special ID that can be passed from one process to another and
> immediately used to access a message queue, semaphore set, or shared memory
> segment, without the overhead of pathname resolution. Very advantageous, as
> a process doesn't have to know what objects it will access in advance in
> order to get at them efficiently.

I doubt that ID's are ever exchanged among processes
so frequently that this overhead would be significant.
This is a very thin silver lining.

Now consider the disadvantages - you cannot examine the size,
ownership, or permissions of shared memory with 'ls'. You can't
copy it with 'cp', move it with 'mv', delete it with 'rm', or
or use tools like 'od', 'strings' and 'grep' on it.

Quote:> A pathname can still be used, with the ftok function.

> One could come up with another approach, of course, but this is a deliberate
> and well-thought-out design choice, not a "botch."

It's clearly not a design choice that was made by the
same folks who gave us the /proc filesystem.

- Show quoted text -

Quote:> > Instead, System V shared memory defines its own funky namespace,
> > and provides idiosyncratic tools like ftok() and ipcs to manage
> > that namespace. It provides a permissions system that basically
> > duplicates filesystem permissions to control access, but you
> > can't use chown/chgrp/chmod to manipulate them.

> Partially agree, and partially covered by my previous comment.

> > POSIX shared memory demonstrates that all of these issues can be
> > dealt with comfortably within the traditional unix filesystem
> > paradigm.

> Don't agree:

> 1. If process A (client) has a POSIX message queue and wants to pass it to
> unrelated process B (server) so B can respond, B has a lot of overhead
> before it can respond, as all it gets is a path. With Sys V IPC, B can
> respond immediately, given only the ID.

> 2. Does not fit comfortably within the "traditional unix filesystem
> paradigm."

By "POSIX shared memory" I was referring specifically to mmap(),
versus the shmctl, shmat, etc APIs. Your caveats below regarding
POSIX message queues are well taken.

- Show quoted text -

Quote:> Pathname is not required to actually exist as a path name, and
> does not on some implementations. Also, only paths that begin with a slash a
> nd have no other slashes are portable, and, on systems that do use an actual
> path, superuser permission may be required for such paths.

> It's an attempt at a clean way to do it, but it's "botched."

> > System V message queues suffer from all of these shortcomings
> > with the additional fault that they are not integrated with the
> > poll() system call, so there is no convenient way for a single-
> > threaded process to block on multiple message queues. (This last
> > is also true of POSIX message queues.) Named pipes (FIFOs) don't
> > suffer these drawbacks.

> Agree. It would be nice if both IPCs allowed you to associate an FD with the
> object, for no other reason than to use select or poll.

> Ditto for other things you wait on: processes to terminate, signals.

> > Doubtless more detailed critiques have been published elsewhere,
> > but I don't have any links handy.

> Well, let me know if you come up with anything else!

It doesn't really matter - SysV IPC is never going to change.
I'd guess that modern unices implement it as a simple layer
on top of POSIX facilities, so it costs little to support it.

-SEan

--
Remove the pi to email me.

by **Marc Rochkin** » Wed, 14 May 2003 07:50:17

[snip]

Quote:
> I doubt that ID's are ever exchanged among processes
> so frequently that this overhead would be significant.
> This is a very thin silver lining.

In this client-server designs that I've used, this is done all the time.
It's one of the main characteristics of Sys V messages that distinguishes it
from alternatives.

[snip]

Quote:
> It doesn't really matter - SysV IPC is never going to change.
> I'd guess that modern unices implement it as a simple layer
> on top of POSIX facilities, so it costs little to support it.

I don't think Sys V IPC is usually layered on top of POSIX, mostly because
it's much older. Also, two systems that have SYS V IPC, Linux and FreeBSD,
don't have POSIX IPC.

--Marc

by **Joerg Brueh** » Wed, 14 May 2003 17:34:13

Hi!

> > response to another thread:

> > I didn't mention specifics, because I think most readers of this
> > newsgroup will be familiar with these time-worn complaints about
> > SysV IPC:

There may be better approaches, but they served us well for a
multi-process, SMP-enabled, client-server application since the
mid-1980s ("Adabas D", a SQL DBMS).

Not having used POSIX IPC until now, I cannot compare that.

Quote:> [...]

> > System V message queues suffer from all of these shortcomings
> > with the additional fault that they are not integrated with the
> > poll() system call, so there is no convenient way for a single-
> > threaded process to block on multiple message queues. (This last
> > is also true of POSIX message queues.) Named pipes (FIFOs) don't
> > suffer these drawbacks.

> Agree. It would be nice if both IPCs allowed you to associate an FD with the
> object, for no other reason than to use select or poll.

Might be difficult: If there is data in a file / FIFO, the next "read()"
(sequential) will get it. With a message queue, the "msgrcv()" supports
selective receipt (by message type), so the condition "there is at
least one message" does not necessarily imply "msgrcv() will not block".

Quote:
> Ditto for other things you wait on: processes to terminate, signals.

Not to forget semaphores, which probably occur much more often.

So I agree that a universal wait mechanism might come very handy,
but I fear it would either lose functionality (compared to the
current "msgrcv()" / "semop()" possibilities) or be extremely
difficult to define and use, not to talk about the time it would
need to spread among the various Unix implementations.

Regards,
Joerg Bruehe

--
Joerg Bruehe, SQL Datenbanksysteme GmbH, Berlin, Germany
(speaking only for himself)

by **Larry Blanchar** » Thu, 15 May 2003 07:45:35

says...

> > I doubt that ID's are ever exchanged among processes
> > so frequently that this overhead would be significant.
> > This is a very thin silver lining.

> In this client-server designs that I've used, this is done all the time.
> It's one of the main characteristics of Sys V messages that distinguishes it
> from alternatives.

I used it frequently in process control and data acquisition systems as
well.

--
To announce that there must be no criticism of the president or that we
are to stand by the president, right or wrong, is not only unpatriotic
and servile, but is morally treasonable to the American public.
Teddy Roosevelt

by **Andrew Giert** » Thu, 15 May 2003 18:25:03

Marc> A pathname can still be used, with the ftok function.

the problem with ftok() is that it does not guarantee uniqueness;
ftok() on different files (different inodes, not just different names)
can return the same key.

Thus, it is never possible to be certain that multiple distinct
applications on the same host using SysV IPC won't unintentionally
conflict, unless none of them use ftok().

--
Andrew.

comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>

by **Marc Rochkin** » Fri, 16 May 2003 01:41:54

[snip]

Quote:> the problem with ftok() is that it does not guarantee uniqueness;
> ftok() on different files (different inodes, not just different names)
> can return the same key.

[snip]

Good point... I forgot about that!

--Marc

by **Bryan Castil** » Wed, 28 May 2003 06:00:54

Quote:
> > System V message queues suffer from all of these shortcomings
> > with the additional fault that they are not integrated with the
> > poll() system call, so there is no convenient way for a single-
> > threaded process to block on multiple message queues. (This last
> > is also true of POSIX message queues.) Named pipes (FIFOs) don't
> > suffer these drawbacks.

> Agree. It would be nice if both IPCs allowed you to associate an FD with the
> object, for no other reason than to use select or poll.

> Ditto for other things you wait on: processes to terminate, signals.

Posix message queues do allow asynchronous notification via mq_notify though.
One of Steven's books describes using a pipe and a signal handler so that
poll/select can be used with a posix message queue (its not pretty though).

(And I have seen it implemented in a program that relays packets between a
socket and a posix message queue - This is a program that use to use a SysV
message queue. The original programmer put a busy wait loop that would
take up 30% of the CPU).

I don't think that SysV message queues provide any notification mechanism, do they?

by **Dragan Cvetkovi** » Wed, 28 May 2003 06:17:04

> Posix message queues do allow asynchronous notification via mq_notify though.

[snip]

Quote:> I don't think that SysV message queues provide any notification
> mechanism, do they?

No, they don't. You have two possibilities: either check queues
periodically (in non-blocking mode) or create a thread that (in blocking
mode) waits on a message in a mq.

Bye, Dragan

--
Dragan Cvetkovic,

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

Very Computer

"System V IPC is a botch?"

"System V IPC is a botch?"

"System V IPC is a botch?"

"System V IPC is a botch?"

"System V IPC is a botch?"

"System V IPC is a botch?"

"System V IPC is a botch?"

"System V IPC is a botch?"

"System V IPC is a botch?"

"System V IPC is a botch?"

"System V IPC is a botch?"

"System V IPC is a botch?"