Re: [guile-2.2] threads

[Thomas Morley]

2017-04-05 19:58 GMT+02:00 Han-Wen Nienhuys :
> LilyPond has no thread-safety anywhere. It would be actively harmful
> if anybody ever tried to run something on a different thread. If
> anything, you should find a way to forbid importing the threads
> package.
>
> On Sun, Mar 26, 2017 at 2:40 PM, Thomas Morley  
> wrote:
>> Hi all,
>>
>> guile-2.2 prints a warning, if module (ice-9 threads) is not imported.
>> (This does not happen with guile-1.8 or guile-2.0)
>> Import (ice-9 threads) to have access to `call-with-new-thread'.
>> Import (ice-9 threads) to have access to `current-thread'.
>>
>> As suggested by Arne Babenhauserheide from the guile-mailing list, in
>> memory-trace.scm we could do something at the lines of
>>
>> ;; TODO if lilypond moves to guile-2.2 merge the next two settings
>> (use-modules (lily)
>>  (ice-9 format))
>> (if guile-v2 (use-modules (ice-9 threads)))
>>
>> This would even be compatible with guile-1.8 (ofcourse one would do it
>> with a little different coding)
>>
>> Though, I think we currently have no need for it. So importing (ice-9
>> threads) would be pointless.
>> If I'm right in this, would there be any other way to avoid this
>> warning-messages?
>>
>>
>> Cheers,
>>   Harm


My purpose was only to get rid of the annoying warning with guile-2.2.

Though, meanwhile I have to state memory-trace.scm is broken since
guile-2.0 anyway, because
trap-set! and trap-enable seems gone since then.
Also, tbh, I've no clue about "enter-frame-handler"...

$ lilypond-git-guile-2.2 -dtrace-memory-frequency=1
../lilypondH/Test/forum/atest-55.ly
GNU LilyPond 2.19.58
Processing `../lilypondH/Test/forum/atest-55.ly'
Parsing...In ice-9/eval.scm:
619:8  4 (_ #(#(#)))
619:8  3 (_ #(#(#)))
   182:19  2 (proc #(#(#)))
   142:16  1 (compile-top-call _ (7 . trap-set!) ((13 15 7 . #) #))
In unknown file:
   0 (%resolve-variable (7 . trap-set!) #)
ERROR: In procedure %resolve-variable:
ERROR: Unbound variable: trap-set!


Looks like memory-trace.scm should be rewritten...

Cheers,
  Harm

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [guile-2.2] threads

[Han-Wen Nienhuys]

On Wed, Apr 5, 2017 at 8:17 PM, David Kastrup  wrote:
> Han-Wen Nienhuys  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

Re: [guile-2.2] threads

[David Kastrup]

Han-Wen Nienhuys  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.

> If anything, you should find a way to forbid importing the threads
> package.

Not sure whether it isn't needed anyhow.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [guile-2.2] threads

[Han-Wen Nienhuys]

LilyPond has no thread-safety anywhere. It would be actively harmful
if anybody ever tried to run something on a different thread. If
anything, you should find a way to forbid importing the threads
package.

On Sun, Mar 26, 2017 at 2:40 PM, Thomas Morley  wrote:
> Hi all,
>
> guile-2.2 prints a warning, if module (ice-9 threads) is not imported.
> (This does not happen with guile-1.8 or guile-2.0)
> Import (ice-9 threads) to have access to `call-with-new-thread'.
> Import (ice-9 threads) to have access to `current-thread'.
>
> As suggested by Arne Babenhauserheide from the guile-mailing list, in
> memory-trace.scm we could do something at the lines of
>
> ;; TODO if lilypond moves to guile-2.2 merge the next two settings
> (use-modules (lily)
>  (ice-9 format))
> (if guile-v2 (use-modules (ice-9 threads)))
>
> This would even be compatible with guile-1.8 (ofcourse one would do it
> with a little different coding)
>
> Though, I think we currently have no need for it. So importing (ice-9
> threads) would be pointless.
> If I'm right in this, would there be any other way to avoid this
> warning-messages?
>
>
> Cheers,
>   Harm
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel



-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel