[Glade-users] Threading with GTK/Glade

[vail newts org (Johnathan Vail)]

Andrae Muys <amuys shortech com au> wrote:
   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 looks like these calls and the examples I found in the docs around
these calls will do what I want to to do.  I thank you all for the
help.

   > 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.
   > 

I don't plan on necessarily migrating my curses programs directly.
But I am looking at new programs using a GUI especially a more user
oriented configuration program.  I would like to explore the event
driven model more but either I am think headed or ignorant of some
major concept here as I still don't see anything but the threads as my
prefered way to go.  Here's why:

In the simplist case I have is a program with 6-10 serial ports
talking to the "gizmos" that the user connects to get configuration
information loaded into.  This is a factory and they run thousands a
day through the system.  The user will insert a gizmo into a fixture
where the software polls a modem control line on the serial port a few
times a second (with usleep() calls between polls).  Once inserted it
starts communicating.  Each configuration takes about 30 seconds with
9600 baud ASTM-1381 framed information.  Each channel as a panel in
the program window where it display the serial number of the gizmo and
the current status as well as a status icon about what the user should
do (like green, it passed or red it failed and take it out).

The communication has several layers: a serial abstraction layer (this
helps me port the upper layers between OS platforms), an ASTM1381
layer, and a device opcode layer.  The application itself is simple
straight line code to communicate with the gizmo and put status to
the screen.  The communication code blocks waiting for responses.  One
instance of this code is spawned in a thread for each channel.

Efficiency of the process is important but the traditional
computational resources are not an issue at all.  The computers are so
fast these days the program is still loafing blocking on the IO and
the time the gizmo takes to proces a command.  There are only about a
dozen calls to the UI during the 30 second run.

I feel that to break up all the layers of the communication as well as
the "main loop" of the application threads would be very tedious and
difficult to maintain.  It doesn't fit any client/server model at all.
It is really just a whole series of steps that need to be done with
only a couple decision points.  Breaking it down and keeping state for
each step seems like it would be much more difficult than working in
the simple straight-line-blocking programming model for each thread.

   > The GUI would fork() and exec() the multi-channel reader process.
   > 

I like this idea.  That would break the multi-channel threaded stuff
into one piece and the simple "display server" GUI program neatly into
another.  I will look further into this.

   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.

Assuming the concurrent programming aspects are simple enough and well
handled (they are) then a simplified programming model is enough of a
reason for me.  Another aspect of the overall problem is the design
spec I work from and validation plans that the program undergoes don't
lend themselves to be broken apart.

Anyway, thanks again for the insight.  I await further
Enlightenment...

jv