[Glade-users] Threading with GTK/Glade

[amuys shortech com au (Andrae Muys)]

James Cameron wrote:
> Johnathan Vail wrote:
> > Does anyone who has done something similar with Gtk have any ideas or
> > suggestions?
>
> Just brute-force lock it.  Before making any GTK+ or Glade call, or
> modification to any data structure that is owned by GTK+ or Glade, take
> out a lock that prevents any other thread in your application from doing
> the same thing.  Take care not to keep the lock.
mmm UGLY! :)  Anyway, I asked Owen Taylor on #gnome how you do this, my
previous suggestion was incorrect.  The correct way to do it is similar
to the synchronise() function Johnathan mentioned in Borland.  Of course
I got a mild rebuke for having failed so dismaly in checking the docs,
in this case the Gtk FAQ which has a link on the front page of
www.gtk.org :).

But in this case you call gdk_threads_enter() and gdk_threads_leave(). 
I'll let you check the docs for more info there.

> It sounds like you have pre-existing code that constrains your design.
> You will not end up with the optimum event driven solution, therefore.
>
> I would probably split the process into two ... change your Linux curses
> threaded program to deliver the data to an interprocess pipe (ipc shmem,
> ipc message queue, network socket or mknod pipe) that is then read and
> processed sequentially by the GUI.
>
> The GUI would fork() and exec() the multi-channel reader process.

I see a number of alternatives that are far less trecherous then
introducing threads into your design.  [Where I've used GIOChannels
here, you can access the loop directly using gtk_input_add(), but I find
GIOChannel's easier].  Note that these options present a reasonable
migration path that isn't too hard to follow as you evolve your
application, I would normally start with either 1 or 2 and pass through
at least 2 of 3,4,5 before reaching 6.

1/ Wrap your file descriptors in GIOChannels and include them directly
in the main loop.

2/ Write an external application that does event driven multiplexing of
the above fd's, and passes any data via a pipe(2) to the GUI, the other
end of the pipe wrapped in a GIOChannel.

3/ If the processing time/io-event is too large to handle more event
sources in the data-collector, run multiple and use 1/ to multiplex
multiple pipe's into the main loop.

4/ As a convenience add the ability to control collector-process
spawn/reaping to the GUI using fork(2)/exec(2).

5/ Split into three tiers by providing a central manager process that
collects, stores, pre-processes the data.  This will likely involve a
move to a MVC model, where you have seperate Model [manager], View
[access], and Controller [manager-admin] tools.  This can include a
View-Controller GUI, an independant CLI admin tool, CLI data-dump tool
for scripting, etc.

6/ Split the above three tiers into two completely independant process
groups.  The manager exposes a well known command/data interface. 
Either via a well known FIFO(poor choice), Unix Domain or TCP/Socket,
SysVIPC shm (ok for data, not good for command), Web (messy
architectually, but marketing love it), or CORBA (nicest of the lot, but
rather complex).

By the time we reach 6 we are scaling far beyond anything a threaded
application could reach, and the architecture is still far easier to
design, debug, and maintain then any threaded alternative.

As I mentioned in private email, I have previously taught threading, and
at last count my course notes were being used by at least two
universities as their introduction to threading tutorials.  On the other
hand, however vital an understanding of concurrency is in a professional
programmer's repetire, few and far between are the uses for it (by
necessity, Operation Systems, high-end computational numerics, and some
scalability problems where the tasks are both highly interdependant, and
togeather far more than one-cpu can handle).

ie.  If you're not writing an OS, and you don't *need* multiple cpu
support (even then fork/exec may be a better option ie. rendering), I
can't think of a situation where threads are the prefered solution.

Andrae Muys