Hi Chris,
2009/1/5 Cris <ternaryd@xxxxxxxxx>:
> I'm having a main loop which is somewhat time critical, and a thread
> which is dedicated to tasks which can take longer and have often a
> lesser priority. I chose to use threads over forks because complex data
I think you have this backwards for glib.
You can't really do anything time critical in the main loop. All it's
there for is repainting the screen and responding to messages from
widgets. Any real-time stuff has to be in worker threads and they
can't (usually) do anthing to the GUI. They need to send messages to
the main thread when they want the display updated.
The system I use is something like this:
// the stuff the bg thread calculates
typedef struct _Packet {
double data[100];
} Packet;
// run as a background thread ... generate a packet of data
// every second
void background_task (void *stuff)
{
for(;;) {
Packet *packet = g_new (Packet, 1);
int j;
for (j = 0; j < 100; j++)
packet->data[j] = (double) rand() / RAND_MAX;
sleep (1);
g_idle_add (new_packet, packet);
}
}
// this is run by the main GUI thread every time a new
// packet of data arrives
gboolean new_packet (Packet *packet)
{
int j;
for (j = 0; j < 100; j++)
update_gui (packet->data[j]);
g_free (packet);
// remove this idle function
// we only want to run once
return FALSE;
}
So a worker thread does something (anything) in the background and
sends data to the main thread with g_idle_add(). The main thread
updates the model and marks the view for refreshing. I don't have
anything to limit the depth of the queue, but in some cases I guess
this might be necessary.
John
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
