CLI using message queue
 

Hello,

I have been trying to implement a full-duplex cli to a daemon I am working on. So far I have been able to either send or receive from my IPC thread but not both. I think that by using something like select() or poll() I should be able to implement both sending and receiving from the message queue in a single thread.

Am I going about this all wrong and should just go the two thread route? It seems like that would be very clunky to require four threads just to handle sending and receiving messages between the daemon and cli application.

Anyone is more than welcome to visit my project and give me hints/tips at improving it. This is the CLI IPC/API I am trying to write.
http://opennop.svn.sourceforge.net/v...68&view=markup

Your guidance would be much appreciated.

It probably depends on when the daemon will need to send information. Does the daemon need to write to the message queue even when no cli process is reading the messages? Are the messages sent by the daemon in response to the incoming messages? I use local sockets for this type of thing, but I only use synchronous IPC for cli/daemon communication.
Kevin Barry

Yes, the daemon will have to send messages back to the cli. The majority of the output will be in response to a message from the cli but some output will be sent to the cli without request. In the case of debug messages being turned on for specific routines it will generate messages and send them to the cli.

So, is it safe to say that the same thing could be done with a socket? Have you considered using a local socket to initiate the connection?
Kevin Barry

Yes, it probably could be done using a local socket. Would my initial problem still remain? If I need a full-duplex/async communications channel wouldnt I still need somehow to break out of the "read socket" in order to send a message?

After you accept a connection, you would set the socket to non-blocking (which can be made default if you you apply it to the listening socket) and use select with a timeout. If you're blocked for a read on a socket then an attempted write should block; therefore, you'd need to either prevent blocking or dup2 the socket so you have a second copy for writing. Alternatively, you could just read from the socket when you have time between other operations; if there isn't any data available then it will fail immediately. If you need buffered input (i.e. a FILE*) then you'd want to avoid select, and instead fdopen then use fgets, etc. to test for and read input at the same time. Lastly, you could set the O_ASYNC flag on the socket and receive a signal when data is made available. In all cases, you'll either need to block somewhere in your code or use some sort of "sleep" to control the processor usage.
Kevin Barry