Very Computer

 John> Hi,
 John> Would appreciate if anybody can tell me whether there is a
 John> "mq_notify" equivalent in the System V implementation of
 John> message queue that tells you whether there is incoming message
 John> in the message queue?

no.

--
Andrew.

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

Quote:>  John> Hi,
>  John> Would appreciate if anybody can tell me whether there is a
>  John> "mq_notify" equivalent in the System V implementation of
>  John> message queue that tells you whether there is incoming message
>  John> in the message queue?

> no.

> --
> Andrew.

 John> Is there a way of alerting a process of an incoming message in
 John> the queue?

Only by having the sender of the message send a notification via some
other channel.

I've written stuff before (many years ago) that worked that way, and
my advice to anyone thinking of doing likewise is "don't even think
about it".

 John> Maybe with a signal or something?

That's how I did it, but I could never be sure (even after taking
extreme precautions, allowing the signal to be unblocked only at a
specific place in the code) that the program wouldn't deadlock or
lose or delay messages due to unfortunate timing. (I could have done
it properly if the platform I was using had pselect(), but like I said
that was years ago, and even now I don't know any systems offhand that
provide it.)

You _might_ be able to make it work properly if you have all three of:
realtime signals, SA_SIGINFO, and sigqueue().

 John> I need to do this because the process has to do other things
 John> and so cannot wait in block mode to receive messages.

Spawn a subprocess (or a separate thread). Have that read the message
queue, and pass the messages to you via some more convenient mechanism.

--
Andrew.

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

Quote:> Only by having the sender of the message send a notification via some
> other channel.

> I've written stuff before (many years ago) that worked that way, and
> my advice to anyone thinking of doing likewise is "don't even think
> about it".

Quote:> That's how I did it, but I could never be sure (even after taking
> extreme precautions, allowing the signal to be unblocked only at a
> specific place in the code) that the program wouldn't deadlock or
> lose or delay messages due to unfortunate timing. (I could have done
> it properly if the platform I was using had pselect(), but like I said
> that was years ago, and even now I don't know any systems offhand that
> provide it.)

> You _might_ be able to make it work properly if you have all three of:
> realtime signals, SA_SIGINFO, and sigqueue().

>  John> I need to do this because the process has to do other things
>  John> and so cannot wait in block mode to receive messages.

> Spawn a subprocess (or a separate thread). Have that read the message
> queue, and pass the messages to you via some more convenient mechanism.

But how is the child gonna communicate with the parent? via pipe or FIFO?
But as i wrote above, according to what limited knowledge i have about pipe
and FIFO, the receiving parent process also cannot be notified of an
incoming message in the pipe. Please enlighten me on this, thanx!

If you're sitting in a loop doing some processing, you can set IPC_NOWAIT
flag for msgrcv to return immediately if there is nothing on the queue and
use that for checking, if you can afford that delay between checkings.

If you're instead sitting in select() or poll() waiting for some event,
then you can't wait for msg queue. You could do select() with rather short
timeout, after timeout check for messages and then go back to select().
In this case it might be easier to replace the msg queue with a pipe
because you can wait for pipe and socket in same select().

But as you were asking for way of notifying, I don't know. Signal that
is but IMHO it is easier to have your reading process to wait for the
queue. This opinion is this because I'm dirt poor in doing signal trapping :)

--

            "concerto for two *s and orchestra"

Quote:>> Only by having the sender of the message send a notification via some
>> other channel.
>Other channels? You mean pipes or FIFO? If I'm not wrong, these 2 methods
>work similarly to msg queue in the way they receive messages.

Quote:>But how is the child gonna communicate with the parent? via pipe or FIFO?

--
okay, have a sig then

 those> they do not work the same.  you can select (or poll) a pipe
 those> but not a message queue (unless you have pselect, which linux
 those> does not).

pselect doesn't have anything to do with message queues; it's the same
as select() but with the addition of a sigset_t parameter for atomically
unblocking signals while waiting (like sigsuspend).

--
Andrew.

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