[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guile threads vs GTK loop

From: Andy Wingo
Subject: Re: Guile threads vs GTK loop
Date: Sun, 15 Aug 2004 11:53:16 +0100
User-agent: Mutt/1.5.6+20040803i

Hey Ondrej,

On Sat, 31 Jul 2004, Ondrej Zajicek wrote:

> - How i can ask whether there are any running guile threads?
>   (To deinstall idle handler where there aren't any.)

I think that single-active-thread?, although not documented, will do
what you want.

> - How i can be informed (some hook?) whether any new running guile thread
>   appeared? (To reinstall idle handler.)

You'll have to write this layer yourself, I think.

Is it really a big performance impact? I would avoid this complexity.
Perhaps you know something I don't :)

> - My Guile-exported C subroutines aren't reentrant. Is there a need to use any
> locking? Happen guile thread switches even during call to C subroutines?

"Do guile thread switches happen ..." :-)

I don't think so. Thread switches can happen when threads are created,
when mutices and signals are operated on, when scm_yield is called, when
SCM_ALLOW_INTS is called, and when SCM_TICK is called. That's not an
exhaustive list. SCM_TICK is called frequently by the evaluator, and is
the result of most thread switches. [Corrolary: `yield' is called all
the time, with little impact in the single-threaded case. Why bother
with removing the idle handler? It should be a timeout handler, btw;
unless you want it to eat all of the CPU.]

So no, there is no signal that drives thread switches. I think that a
call to a C subroutine would block the app. However, all of the above is
just from reading the source; I personally haven't used threading in 1.6.

Andy Wingo <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]