Hi,
I've been investigating the behaviour of threads created in the same
lexical scope, and I have to admit that I'm a little puzzled.
The documentation states, that the "call-with-new-thread" procedure calls
its argument in a new thread and with a new dynamic state, the latter being
described in m
(sorry, I accidentally pressed ctrl+return, which caused my mail client to
send the message).
So here's the code:
(for-each
(lambda(i)
(let ((thread (call-with-new-thread
(lambda ()
(sleep (+ (random 10) 2))
(format #t "w
Oh, I just realized that each thread was created in a new closure anyway,
so they weren't able to share the variable. Sorry for the confusion.
2014/1/14 Panicz Maciej Godek
> Oh, I just realized that each thread was created in a new closure anyway,
> so they weren't able to share the variable. Sorry for the confusion.
>
It was a confusion, because the lexical scopes of threads are obviously
shared.
> "Ludovic" == Ludovic Courtès writes:
Ludovic> I guess this is another limitation of Guile’s current signal handling
Ludovic> strategy, and something we should fix.
FWIW I think it would be sufficient for gdb if scm_system_async_mark, or
something like it, could be invoked from a signal han
hi there!
On Tue, 2014-01-14 at 00:17 +0100, Panicz Maciej Godek wrote:
> Another option would be to use
> (substring (utf8->string buffer 0 n))
>
> This one works, but according to the manual, the
> string is "newly allocated", so it's unnecessary overhead.
>
Actually, substring is COW(copy-on
