On Wed, Apr 5, 2017 at 8:17 PM, David Kastrup <d...@gnu.org> wrote:
> Han-Wen Nienhuys <hanw...@gmail.com> writes:
>
>> LilyPond has no thread-safety anywhere. It would be actively harmful
>> if anybody ever tried to run something on a different thread.
>
> The Boehm GC garbage collector defaults to running in its own thread.
> It is set to "Java" collection semantics which separates marking and
> finalization phases.
It's not about the garbage collection. It's about shared state. Consider
SCM l ; // global variable
void add(SCM val) {
SCM new_head = scm_cons(val, l);
l = new_head;
}
if you have two threads doing this without synchronization, there is
no guarantee on what you'll end up with. Most likely, one of the
updates would get lost, but I have seen thread-unsafe use of STL
hashmaps result in cyclical lists, for example, and I wouldn't be
surprised if that could happen here too.
Or imagine that two threads try to lookup a font by calling into
fontconfig at the same time. LilyPond has one global font-config
instance (see lily/font-config.cc), and fontconfig is not thread-safe.
>> If anything, you should find a way to forbid importing the threads
>> package.
>
> Not sure whether it isn't needed anyhow.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwe
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
