Add a unix signal number in the signal handler, and suck it out
again in a custom event source's prepare method. The prepare
method can return -1 for its timeout contribution, and true/false
if there's something in the queue.
So... poll *will* exit because of the signal... but will it
Freddie Unpenstein wrote:
You are absolutely right; mutexes /are/ useless from signal
handlers. It seems the only reasonable way is to use a pipe().
How about GAsyncQueue's? They're supposed to be thread safe without the need
of locking... How about within a single
Freddie Unpenstein wrote:
That's well over 1548533 executions (I forgot to print the
counter after the 10th second) of the idle callback, or
172059 calls to the idler function per second. Personally,
I'd call that a busy wait.
Its not a busy wait; your idle handler has never returned
On Thu, Mar 16, 2006 at 03:40:08PM -0500, Tristan Van Berkom wrote:
Yes sure, but why would you want to use a flag... when you can just call
g_idle_add
*from the signal hanlder*
Is g_idle_add() really reentrant? It does not look so at
the first sight.
Yeti
--
That's enough.
David Necas (Yeti) wrote:
On Thu, Mar 16, 2006 at 03:40:08PM -0500, Tristan Van Berkom wrote:
Yes sure, but why would you want to use a flag... when you can just call
g_idle_add
*from the signal hanlder*
Is g_idle_add() really reentrant? It does not look so at
the first sight.
On Thu, Mar 16, 2006 at 03:55:50PM -0500, Tristan Van Berkom wrote:
Well, it locks a mutex before accessing the GMainContext; so if gtk+ is
compiled with threads... it should work... unless I'm on crack and mutexes
are useless from signal handlers... but I dont think so.
Maybe I'm missing
David Necas (Yeti) wrote:
On Thu, Mar 16, 2006 at 03:55:50PM -0500, Tristan Van Berkom wrote:
Well, it locks a mutex before accessing the GMainContext; so if gtk+ is
compiled with threads... it should work... unless I'm on crack and mutexes
are useless from signal handlers... but I dont
Going back to your original point, it is definitely not a
busy wait.
I just rolled together a quick test... A GTK main loop running two sources.
First an event source created using g_timeout_add() that prints the current
count each second, and halting the program (via gtk_main_quit() )
Thomas Okken schrieb:
I would like to catch SIGINT in my GTK+ application,
to do a graceful exit. I was looking for the GTK+
equivalent of XtNoticeSignal(), but I guess there
isn't one;
No, I'm missing them too...
I read a few articles discussing the use of a pipe,
with an input source to
Chris Vine wrote:
On Saturday 11 March 2006 22:36, Thomas Okken wrote:
[Using a pipe] is generally the best way of dealing
with asynchronous (Unix) signals, but for simple
cases another approach is just to set a flag of type
volatile sig_atomic_t in the Unix signal handler,
and
Gus Koppel wrote:
However, if you know your application belongs to the
majority of GTK+ applications, that is, it stays in
the
outermost main loop, spending most of its time
actually
being idle, then using the idle handler may be
appropriate. But as explained, it's not quite as
fail-safe
On Saturday 11 March 2006 10:22, Gus Koppel wrote:
Thomas Okken wrote:
I would like to catch SIGINT in my GTK+ application,
to do a graceful exit. I was looking for the GTK+
equivalent of XtNoticeSignal(), but I guess there
isn't one; when I searched the archive, all I found
was some
On Saturday 11 March 2006 22:36, Thomas Okken wrote:
[Using a pipe] is generally the best way of dealing
with asynchronous (Unix) signals, but for simple
cases another approach is just to set a flag of type
volatile sig_atomic_t in the Unix signal handler,
and then check and act on the
13 matches
Mail list logo
