[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: wip-ports-refactor
From: |
Andy Wingo |
Subject: |
Re: wip-ports-refactor |
Date: |
Tue, 10 May 2016 16:30:30 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Hi :)
On Sun 24 Apr 2016 13:05, Chris Vine <address@hidden> writes:
> on the question of guile's thread implementation, it seems to me to be
> basically sound if you avoid obvious global state. I have had test
> code running for hours, indeed days, without any appearance of data
> races or other incorrect behaviour on account of guile's thread
> implementation. Global state is an issue. Module loading (which you
> mention) is an obvious one, but other things like setting load paths
> don't look to be thread safe either.
I think we have no plans for giving up pthreads. The problem is that
like you say, if there is no shared state, and your architecture has a
reasonable memory model (Intel's memory model is really great to
program), then you're fine. But if you don't have a good mental model
on what is shared state, or your architecture doesn't serialize loads
and stores... well there things are likely to break.
I like to recommend solutions that will absolutely work and never crash.
(They could throw errors, but that doesn't crash Guile.) I can't do
that with threads -- not right now anyway. If you know what you're
doing though, go ahead and use them :)
Andy
- Re: wip-ports-refactor,
Andy Wingo <=