Hallvard B Furuseth wrote:
> Is it possible to remove a msgget() message queue from a child
> which is going to execvp(), while keeping the queue in the parent?

> At least on Linux the queue survives both fork() and execvp(), and
> msgctl(queue, IPC_RMID, NULL) in the child then removes the queue
> in the parent as well.

What do you mean by "remove a message queue while keeping it"?
There's a single message queue kept by the kernel. It's not be-
longing to a certain process, so every process with the permis-
sions to remove it can do that. On the other hand, the message
queue even "survives" all processes exiting - if nothing deletes
it it will continue to exist until the machine gets rebooted.

What you write about "surviving fork() and execvp()" lets it
look as if you assume that the message queue is a kind of
per-process thing. But it isn't. It belongs to the kernel
and can be manipulated by those processes having the neces-
sary permissions. So persistence- and permissions-wise it's
more or less like a file on a RAM disk. If the child process
doesn't need the message queue but some other process still
does the child should simply leave it alone.

Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de

On 7 Jul 2008 21:01:50 GMT Jens Thoms Toerring wrote:

| What do you mean by "remove a message queue while keeping it"?
| There's a single message queue kept by the kernel. It's not be-
| longing to a certain process, so every process with the permis-
| sions to remove it can do that. On the other hand, the message
| queue even "survives" all processes exiting - if nothing deletes
| it it will continue to exist until the machine gets rebooted.

I've always considered it sad that message queues work that way.

I want a message system which is like a pipe or socket, including
the ability for messages to be picked up by one of many processes,
but where the messages are all cleared out as soon as all descriptors
to the receiving end are closed (which would be if all the processes
exit). Unlike a stream, it needs to convey a boundary. Datagrams
might do the job but they are not connection based. SCTP looks to
be a useful facility, but I don't know if those semantics can be
used in a unix-domain socket (they can over internet protocol, of
course).

--
|WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
| by the abuse department, bellsouth.net is blocked. If you post to |
| Usenet from these places, find another Usenet provider ASAP. |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

Jens Thoms Toerring writes:
> What do you mean by "remove a message queue while keeping it"?

Well, remove access via the message queue indentifier returned from
msgget(). Called with IPC_PRIVATE, I should have mentioned that.
Similar to close(file descriptor opened in parent).

The integer itself doesn't seem to provide access to the queue:
prog1:
int q = msgget(...);
printf("%d\n", q);
...
prog2:
msgsnd(integer printed by prog1, ...);
I've tested this, it only works if prog2 is fork & exec'ed by prog1.

> (...) If the child process doesn't need the message queue but some
> other process still does the child should simply leave it alone.

I'd prefer not need to trust the child with the queue.

--
Hallvard

Hallvard B Furuseth wrote:
> Jens Thoms Toerring writes:
> > What do you mean by "remove a message queue while keeping it"?

> Well, remove access via the message queue indentifier returned from
> msgget(). Called with IPC_PRIVATE, I should have mentioned that.
> Similar to close(file descriptor opened in parent).

> The integer itself doesn't seem to provide access to the queue:
> prog1:
> int q = msgget(...);
> printf("%d\n", q);
> ...
> prog2:
> msgsnd(integer printed by prog1, ...);
> I've tested this, it only works if prog2 is fork & exec'ed by prog1.

> > (...) If the child process doesn't need the message queue but some
> > other process still does the child should simply leave it alone.

> I'd prefer not need to trust the child with the queue.

I guess the best thing you can do is set the inherited message
queue identifier to a non-valid (negative) value and thus have
the process forget how to access the message queue. There's no
close-like function, but if you don't have the identifier any-
more it's at least not trivial to find the queue (you would
have to run through INT_MAX/2 potential idenifiers on average
to get at it;-) And if you call execvp() directly after the
fork() then even that isn't necessary since the identifier
won't be available anymore in the new executable.

Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de

On Jul 8, 1:13*am, Hallvard B Furuseth
wrote:
> Is it possible to remove a msgget() message queue from a child
> which is going to execvp(), while keeping the queue in the parent?
>
> At least on Linux the queue survives both fork() and execvp(), and
> msgctl(queue, IPC_RMID, NULL) in the child then removes the queue
> in the parent as well.
>
> --
> Hallvard

That seems unlikely as there is a single message queue. The queue is
not duplicated for child. If you close it in the child process, it
will be closed for the parent as well.