Re: g_main_loop and g_async_queue
- From: Cris <ternaryd gmail com>
- To: gtk-list gnome org
- Subject: Re: g_main_loop and g_async_queue
- Date: Mon, 5 Jan 2009 09:44:52 -0200
On Mon, 5 Jan 2009 11:15:18 +0000
jcupitt 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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]