GUI Interface to a running Daemon

ROOT
1

I am pretty sure that this question is well documented elsewhere as it is probably a very common issue, but in my searching I havent been able to find it. Here is my problem:

I have a daemon that runs a piece of equipment. That is, it sends and receives signals every minute or so. While its not sending or receiving, it is sleeping. The daemon is a singleton class.

I also have a GUI interface that can update settings to the instrument. It is all written using TGFrames, and the top frame loads with a parent gClient->GetRoot(). The GUI is also a singleton class.

Now the problem:
If I run this as a single process, I can not interact with the GUI while the process is sleeping in the daemon.

Solutions I can think of:

  1. Fork the process using fork() and use pipes to communicate between the two processes. This is aggravating because I have to write data back and forth by writing information to pipes. I can do this, but I would rather avoid the low level pipe processes.
  2. Since both the daemon and the GUI are singleton classes, I would rather share the memory between the two processes and avoid piping data all together. I know there are memory sharing capabilities in the boost libraries, but does ROOT have similar things? The nice thing here, is that both processes are simultaneously accessing the same memory space, and the daemon can do nothing but sleep while its not talking to the instrument.
  3. Open the GUI and the daemon as two separate processes (or fork them) and communicate between them using TSockets. This has the advantage of being able to close the GUI and leave the daemon running, re-open the GUI and re-connect to the daemon. But if I do this, then I have to tell the daemon to continually check the socket for new information.

Now, I am sure this is a commonly done thing. And I am hoping that ROOT has a more elegant solution?

2

Hi,

You should have a look at the examples in tutorials/net, e.g. spyserv.C and spy.C, hserv.C and hclient.C, hprod.C and hcons.C, you will probably find the solution to your problem.

Cheers, Bertrand.

3

For future interest:

Spy.C and SpyServe.C use TSockets, which is, in essence, approach 3.

This is what I wound up using. This is somewhat annoying because I have to write the data to the socket buffer, send it and then read it. Since the instrument is slow (only needs to be updated every tens of seconds), this works. But, if this were fast, this might require a lot of overhead.

4

Well, you can also use shared memory (e.g. using hprod.C & hcons.C approach)…

Cheers, Bertrand.