> > 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 wi
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 thread?
> 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 thread?
Add a unix signal number in the signal ha
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 thin
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 so
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: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.
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 FAL
> > 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 FALSE;
> so whenever
Chris Vine <[EMAIL PROTECTED]> writes:
> That's not right. Idle handlers do not busy wait. They do trigger
> invocations of the event loop at indeterminate intervals. They are also very
> common (if you don't want to communicate with the glib event loop from other
> threads with a pipe, you
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 ha
Freddie Unpenstein wrote:
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 pro
> 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()
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-
On Sunday 12 March 2006 10:49, Gus Koppel wrote:
> Chris Vine wrote:
[snip]
> > That's not right. Idle handlers do not busy wait. They do trigger
> > invocations of the event loop at indeterminate intervals. They are also
> > very common (if you don't want to communicate with the glib event lo
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 handle
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
> [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 status of the flag in
> the glib event loop with an idl
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
> > w
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 mention of a proposed GLib extension called
> g_signal
20 matches
Mail list logo
