Re: wip-ports-refactor

[Andy Wingo <wingo@pobox.com>]

On Wed 11 May 2016 12:42, Chris Vine <chris@cvine.freeserve.co.uk> writes:

> So you are saying that some parts of guile rely on the ordering
> guarantees of the x86 memory model (or something like it) with respect
> to atomic operations on some internal localised shared state?

Let's say you cons a fresh pair and pass it to another thread.  So first
Guile will allocate the pair then it will initialize the car and cdr
fields.  Does the other thread see the "car" and "cdr" values which the
first one set?

In Intel, yes.  But not all architectures are like that.  Storing a
value to the "car" of a pair might not imply any ordering with respect
to a read to that same memory location from another thread.  AFAIU
anyway.

> Looking at the pthread related stuff in libguile, it seems to be
> written by someone/people who know what they are doing.  Are you
> referring specifically to the guile VM, and if so is guile-2.2 likely
> to be more problematic than guile-2.0?

I think Guile 2.2 is likely to be better if only because the port
situation is better there, and also weak maps are thread-safe (because
they lock now).  Otherwise no significant change.

Andy