Like we can do, poll/epoll/select on an fd, we can not on msg queue id. I found some non standard methods to make msgqueue-id to fd, but afterall its a non standard. So my question is, Why linux geeks, not implemented poll/select on msg queue id ? Does that lead to serious issue ?

I need to implement such sort of mechanism. How can I do that ?

I think we have to assume that if it were feasible, it would have been done by now. It is probably a case where the API seems to resemble the file-descriptor case, but the underlying mechanisms are sufficiently different that it is difficult or impossible to implement. Just my guess.
--- rod.

1 members found this post helpful.

msgget() et al. is part of System V IPC, which dates back three decades. For all practical intents and purposes, it is fixed in stone; any change, however small, is likely to break a large number of installed programs. We don't do that.

Well, non-Linux banal person, because you should use POSIX message queues instead, because their interface is better. In Linux, a POSIX message queue is a file descriptor. See the end of man 7 mq_overview for details.

If you need to use poll, epoll, or select with a System V message queue, even in portable code, create a socket pair, and either a thread or a child process. Have the thread/child block in a call to msgrcv(id, &dummy_msgbuf, 0, 0, 0). As the length is zero, it will not read the message. Whenever the call returns, have the thread/child issue a one-byte write to the socket, then a one-byte read, and finally call msgrcv() again. Continue until the message queue is closed, or the socket is closed. (Close the other one, too, and return (if thread) or exit (if child process). That way the main process does not need to worry about it after creating it; the thread/child will clean itself up when it is no longer needed.)

In your poll/epoll/select routine, when the socket becomes readable, receive the messages in a loop using msgrcv(,,,,IPC_NOWAIT), until the return value is -1 with errno==ENOMSG. Write one byte to the socket, and your message queue has been serviced.

This approach should need only about a hundred lines of clean C to implement. Since the thread/child process will be sleeping all the time, it will not consume any significant CPU time. It also needs very little memory, because it does not read the actual messages, and it only sends and receives single bytes via the socket. The "cost" of this approach is minimal.

It rather seems to me you have decided you want to use one specific approach, and are wailing because we don't see how superior that approach would be. The reality is, you have multiple possibilities and avenues to solving whatever your underlying problem might be. You even have a nice workaround to the perceived "lack". Now, go code!

Hope this helps,

1 members found this post helpful.

thnx, Nominal Animal, It was very very useful.