> 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.
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."
Partially agree, and partially covered by my previous comment.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.
> POSIX shared memory demonstrates that all of these issues can be
> dealt with comfortably within the traditional unix filesystem
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."
Agree. It would be nice if both IPCs allowed you to associate an FD with theQuote:
> 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.
object, for no other reason than to use select or poll.
Ditto for other things you wait on: processes to terminate, signals.
Well, let me know if you come up with anything else!Quote:
> Doubtless more detailed critiques have been published elsewhere,
> but I don't have any links handy.