Re: g_main_loop and g_async_queue
On Mon, 5 Jan 2009 11:15:18 + jcup...@gmail.com wrote: Thanks, John, 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. It's not really that time critical nor actually real-time; nothing will break for a delay of a few ms and granularity is essentially a few ms. g_main_loop() is working fine for that, also because it simplifies mixing many different types of events. But the secondary tasks can take several seconds up to minutes (but it also can be fast) depending on factors which can't be controlled ahead of time. So I needed to separate these two things. But I forgot to mention, that this is not a gtk or gdk but only a glib program, without GUI or user interaction. I think, I'll stick to the solution using pipes, as it's starting to work. But it would be nice, if g_main_loop() had some magic to wait for a blocking mutex as does poll() waiting for a file descriptor becoming read or writable. Unfortunately, polling such a mutex with trylock over some time interval isn't an option in this case, as the overhead would be too big. Thanks, -- Chris ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_main_loop and g_async_queue
On Mon, 5 Jan 2009 11:15:18 + jcup...@gmail.com wrote: Thanks, John, 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. It's not really that time critical nor actually real-time; nothing will break for a delay of a few ms and granularity is essentially a few ms. g_main_loop() is working fine for that, also because it simplifies mixing many different types of events. But the secondary tasks can take several seconds up to minutes (but it also can be fast) depending on factors which can't be controlled ahead of time. So I needed to separate these two things. But I forgot to mention, that this is not a gtk or gdk but only a glib program, without GUI or user interaction. I think, I'll stick to the solution using pipes, as it's starting to work. But it would be nice, if g_main_loop() had some magic to wait for a blocking mutex as does poll() waiting for a file descriptor becoming read or writable. Unfortunately, polling such a mutex with trylock over some time interval isn't an option in this case, as the overhead would be too big. Thanks, -- Chris ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_main_loop and g_async_queue
Hi Chris,
2009/1/5 Cris terna...@gmail.com:
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@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_main_loop and g_async_queue
On Mon, 5 Jan 2009 09:56:24 + Chris Vine ch...@cvine.freeserve.co.uk wrote: On Mon, 5 Jan 2009 07:45:02 -0200 Cris terna...@gmail.com wrote: Is there a way to have the main loop react upon a message becoming available from a different thread on an asynchronous queue? 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 sets need to be exchanged between the two. Is there some other method I could use instead of asynchronous queues? g_idle_add(), or g_idle_add_full(), are intended for use for message passing to the event loop of the main program thread. They are thread safe. My problem is with the communication coming from the secondary thread, signaling the primary that it can get a result. How could this be done using the idle function? Also, if the idle function is only called if the normal (time critical events) processing is idle, in this case, it would be called probably almost never, as it can get quite busy. There is a solution to it, using standard unix pipes as I would do using forked processes rather than threads (but with those I would have to encode and decode complex data structures while with threads I can get away using mutexes). With g_io_add_watch I can have the main loop trigger my function whenever the secondary thread has finished a job and sends some random byte. I was wondering however, if there is a more glib-style solution to it. Thanks, -- Chris ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
g_main_loop and g_async_queue
Hi, Is there a way to have the main loop react upon a message becoming available from a different thread on an asynchronous queue? 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 sets need to be exchanged between the two. Is there some other method I could use instead of asynchronous queues? Thanks, -- Chris ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
RE: g_main_loop
Hi All, I am a beginner to gtk APIs. My query is : - In Thread T1 I am calling g_main_loop() - In Thread T2 I am emitting a signal through g_signal_emit_by_name(G_OBJECT, signal-name); I saw that signal handler is running in Thread2 context. I want that it should run in Thread 1 context. How I can achieve this? Regards, Harish Haswani, LJ-P2P, GRAPHICS, MME Group, MIEL, Bangalore, INDIA Ph: 91-80-26014164 ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
g_main_loop
Hi All, I am a beginner to gtk APIs. My query is : - In Thread T1 I am calling g_main_loop() - In Thread T2 I am emitting a signal through g_signal_emit_by_name(G_OBJECT, signal-name); I saw that signal handler is running in Thread2 context. I want that it should run in Thread 1 context. How I can achieve this? Regards, Harish Haswani, LJ-P2P, GRAPHICS, MME Group, MIEL, Bangalore, INDIA Ph: 91-80-26014164 ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_main_loop
On Tue, 2008-07-15 at 19:15 +0800, HASWANI HARISH-VCKR47 wrote:
Hi All,
I am a beginner to gtk APIs.
My query is :
- In Thread T1 I am calling g_main_loop()
- In Thread T2 I am emitting a signal through
g_signal_emit_by_name(G_OBJECT, signal-name);
I saw that signal handler is running in Thread2 context. I want that
it should run in Thread 1 context. How I can achieve this?
best to think of some other model. gobject signals do not (trivially)
cross thread boundaries. the most widely adopted approach is to use
g_idle_add() to (thread-safely) add an idle callback that emits the
signal from the correct (g_main_loop()) thread:
gboolean foobar (gpointer foo) {
g_signal_emit_by_name (foo, signal-name);
return FALSE;
}
in thread T2:
...
g_idle_add (foobar, G_OBJECT);
...
something like that, anyway.
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
g_main_loop
Hi All, I am a beginner to gtk APIs. My query is : - In Thread T1 I am calling g_main_loop() - In Thread T2 I am emitting a signal through g_signal_emit_by_name(G_OBJECT, signal-name); I saw that signal handler is running in Thread2 context. I want that it should run in Thread 1 context. How I can achieve this? Regards, Harish Haswani, LJ-P2P, GRAPHICS, MME Group, MIEL, Bangalore, INDIA Ph: 91-80-26014164 ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_main_loop
Just a guess, but I'd try putting a function in Thread 1 that emits the signal, but call that function from Thread 2. This way, Thread 2 controls when the signal is emitted, but the signal is still handled by Thread 1. Never actually tried this myself, though, so I don't know for sure if one thread can call a function in another thread. Ed James 2008/7/15 HASWANI HARISH-VCKR47 [EMAIL PROTECTED]: Hi All, I am a beginner to gtk APIs. My query is : - In Thread T1 I am calling g_main_loop() - In Thread T2 I am emitting a signal through g_signal_emit_by_name(G_OBJECT, signal-name); I saw that signal handler is running in Thread2 context. I want that it should run in Thread 1 context. How I can achieve this? ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_main_loop
A function is just a piece of code, so if you call a function in T1 from T2, you still call it in the context of T2; the only thing really helping here is having a maincontext in T1 and T2, and using a g_idle_add() *on* the maincontext of T1 (but the code that adds it can be called from T2) so the idle handler can call some code with the context of T1. Am 15. Juli 2008 16:38 schrieb Ed James [EMAIL PROTECTED]: Just a guess, but I'd try putting a function in Thread 1 that emits the signal, but call that function from Thread 2. This way, Thread 2 controls when the signal is emitted, but the signal is still handled by Thread 1. Never actually tried this myself, though, so I don't know for sure if one thread can call a function in another thread. Ed James 2008/7/15 HASWANI HARISH-VCKR47 [EMAIL PROTECTED]: Hi All, I am a beginner to gtk APIs. My query is : - In Thread T1 I am calling g_main_loop() - In Thread T2 I am emitting a signal through g_signal_emit_by_name(G_OBJECT, signal-name); I saw that signal handler is running in Thread2 context. I want that it should run in Thread 1 context. How I can achieve this? ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
g_main_loop and persistant connections
Hi, I'm having problems to design a python network application, that is like a messenger. In this app, the user would be able to send and receive messages. There are persistant connections involved, mainly because it is possible to receive messages asyncronously. I would like to handle these permanent connections in differents threads, so the GUI doesn't halt when sending, receiving or even wainting a message, but *How the main thread (the GUI, locked in g_main_loop) is awaken by the connection handler threads when a message arrives * I don't understand how the connection threads call functions that should be run in the main thread when this one is iterating the main loop. *Can different threads make modifications in the widgets?* (using the appropiate locks, barriers when needed). Can someone point to a nice howto/tutorial about this? Any help would be appreciate since I've never written an application like this and I am kind of fully-lost about this. Thanks in advance, even for reading up to here. Matías ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
threads and multiple g_main_loop
Hi all, i've a multithreaded program and each of this threads have a g_main_loop. All seems to work fine but sometimes it lock. Can this way (have multiple g_main_loop in multiple threads) cause critical situations to my program ? Thanks, Oz -- O-Zone ! No (C) 2005 WEB @ http://www.zerozone.it BLOG @ http://blog.zerozone.it/user/o-zone ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: threads and multiple g_main_loop
On Mon, 2006-07-10 at 13:37 +0200, Michele O-Zone Pinassi wrote: Hi all, i've a multithreaded program and each of this threads have a g_main_loop. why? ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_main_loop() seems stuck
The above works 100% of the time when it is only one critical response
dialog that is handled. If after I return to the engine code in the
above scenario it is followed in rapid succession with another UI
callback I go through all the motions and end up blocking in the
g_cond_wait() and no window shows up. This happens 80% of the time.
this is the archetype of a race condition. i would expect that
somewhere, you are not using the locks correctly (i.e. not taking them
at the right points and releasing them at the right points). issues
with condition variables are common sources of simple race conditions
because (for some strange reason) they are not well understood.
you will probably not be able to track such bugs in gdb, because gdb's
control over the app changes its execution timing, and thus changes
the probabilities of encountering the bug. thats also probably why it
works over telnet/ssh - execution speed of each thread is changed by
the network latency.
most of the people i know who do multithreaded programming with GTK
(myself included) do not bother with gdk_thread_{enter,leave}, but
instead have a single thread making GTK/GDK calls. all other
threads writing requests to a pipe that is monitored by the main glib
event loop from the main gui thread. this removes the need to use the
gdk thread lock (you don't even need g_thread_init()), and makes sure
that this type of condition does not come from the GUI code.
--p
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
