I have a process that is blocked in msgrecv as shown by "ps -eo pid,tid,wchan" . Is there any way to find the PID of the process that my process is expecting to receive a message from? The communication method used is message queues using the methods provided in sys/msg.h

It stands to reason that you ought to know that, about your process.

If I have 2 processe that communicate through a message queue, yes I will know this about my process. But if this process is part of a bigger picture, if it communicates with more than one other processes, it's there a way which one of these processes it's maybe stuck and can't send the reply that my process is waiting for?

Seems like this is very similar to your other thread http://www.linuxquestions.org/questi...re-4175535835/

Basically, these processes started somewhere. The main point where they start should be something written by you and what you can do from there is keep track of the child processes you create, and continue to do so if those children continue to perpetuate making child processes of their own.

That's not me patronizing, I am an embedded programmer who has used real RTOS's. Linux is not exactly that, there are facilities to keep track of processes and their states, and I feel that the best way to do this program-wise is to be a parent process which knows the sub-processes it created and manages things.

Linux does not have facilities auto-provided and as elaborate as the RTOS vendors do to monitor IPC queues and processes. This doesn't mean that you couldn't develop them for your own use.

My $0.02 on that however is that writing a generic tool to look at and monitor processes might be good and useful for command line debugging, it will not ultimately serve you well. Why? Because the parent process is named this for a reason, it gets signals from the child processes when they end, therefore the parent process is the location where you should have your monitoring code.

As far as a process having been blocked awaiting a message. In a blocking architecture, that's exactly the situation. So you either design for non-blocking or blocking and there are different techniques to deal with each. Personally I prefer non-blocking and either with zero timeouts and thus quick yields or lengthy timeouts to ensure that I don't end up having a stuck process. Further, if there's nothing to do for a given process and that is by definition a problem, then identifying the problem via that processing having a long term timer expire will then give you the capability to highlight a system or data flow issue in your logs or to something more noticeable to a person.

Checkout some of my blogs on Linux Applications, really many of them are about IPCs and Daemons: http://www.linuxquestions.org/questi...n-programming/