[Top][All Lists]

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

Re: Guile thread safety.

From: Chris Cramer
Subject: Re: Guile thread safety.
Date: Sun, 7 Oct 2001 02:11:57 -0500
User-agent: Mutt/1.2.5i

On Sat, Oct 06, 2001 at 09:30:26PM +0100, Neil Jerram wrote:
> >>>>> "Kai-Peter" == Kai-Peter G Backman <address@hidden> writes:
>     Kai-Peter>  The ideal solution would be one where all threads
>     Kai-Peter> could use gh_ and scm_ interfaces and I could handle
>     Kai-Peter> application level concurrency when needed.  The next
>     Kai-Peter> best solution would have calls like
>     Kai-Peter> "guile_threads_enter" and "guile_threads_leave" to
>     Kai-Peter> guard access to the scheme environment.
>     Kai-Peter>  Will my ideal solution be realised in 1.6? If not, how
>     Kai-Peter> do I create that next best solution?
> Right now, I think we even have problems with the coexistence of coop
> threads and pthreads, even when only one of the pthreads uses Guile.

IIRC if you keep Guile to only one pthread, it works fine.
1.6 won't have anything different from 1.4 in terms of thread support.

> My guess is that 1.8 will solve this coexistence problem and support
> multiple pthreads using Guile by dispatching requests onto a queue,
> but no further.  The issues involved in going beyond this are really
> hard!

I'm not going to speculate on which post-1.6 releases will have what
type of thread support, but full pthread support is possible. (On Linux,
anyway; I don't use anything else so I haven't bothered to research how
pthreads work on other systems). The only thing that I think would be
hard is keeping memory allocation from going very slow, but I may just
be unaware of some easy trick to doing it.

C. Ray C. aka Christopher Cramer

reply via email to

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