GTK+ Forums

Dear all,
I've been working on dynamic real time colormap and histogram plotting using GTK+. In the code, I've a parent process which returns to the main application after initializing all GTK Widgets. A child process created from the parent before returning to main application, calls gtk_main and performs dynamic plotting using two timer handler functions. Parent process passes data to the child process as and when it becomes available. In other words, parent process is the producer of data and child process is the consumer. I want to add a function to close the Gtk window from parent process. I am unable to do so because the gtk_main_quit can't be called in the context of parent process. I tried to emit destroy signal from parent process but it seems that the event handler is getting executed in the context of parent process as I'm getting following error:

Any suggestions on how to proceed?

This idea seems to violate the GTK requirement that all calls to GTK should be performed from the same thread (process). If you have your child handling all other GTK stuff, then the obvious way to go is to have the parent indicate to the child to call gtk_main_quit by some means of inter-process communications. This way the parent abstains from all GTK calls.

This is what I'd do:
From what you write here, a good choice seems to have the parent send the child a signal. I guess the child will terminate after returning from gtk_main(), in that case it may be appropriate to send SIGINT, and have the child catch it and set some internal flag upon reception. The child can have a gtk_timeout function that is called regularly to check for the flag and call gtk_main_quit() if set.

Cheers Peter

Hi,

Peter is right, but his solution is overly complicated and wasteful on resources.

From the description of your application I am not totally clear on the layout. So I will assume that you are using threads and not some other method of splitting your application into multiple processes. If you are using some thing else then please let us know.

As to a solution I would use g_idle_add() which is in Glib to add a call back function which will then be called in the GUI thread. Note that Glib is thread safe and will perform any locking that is needed.



As a note gtk_timeout_add() which is what Peter suggested to use has been deprecated since GTK+ 2.4, with the two series now on 2.24.9. If you do need it then you should use g_timeout_add() instead. Note that this is resource wasteful as it will be a busy loop looking at changes in a variable every loop, and you could be using that CPU time for your real-time application instead. Note that Peter had missed out the locking that is still needed.

_________________
E.

Thanks a lot for the suggestions Peter and Errol. I've used a named semaphore to signal the child process from parent process for now. I am using fork for process spawning as of now. This solution works out well now. I'll definitely try to implement the more efficient & elegant alternative suggested by Errol.

Cheers,
Sameer.

Since you are using fork() to create a new process my method of using g_idle_add() will not work as they will be in two different processes and this method can only communicate between threads in a single process. If you were using threads so, one processes, but many threads then it will work.

There are ways around this, if a little bit more complex. You could use pipes to communicate to the GUI process and have the GUI main loop monitor the pipe. That way you can read in commands and execute what is needed depending on what command is sent via the pipe. But there are many more inter process communication methods, so depending on the structure of your application you can then choose which one most suits you.

_________________
E.