for the first problem, you've found a bug in the Racket CS thread
scheduler (i.e., Racket BC behaves correctly in this case). Suspending
a thread that is sleeping didn't prevent the thread from being woken up
on its previous schedule. I've pushed a repair as commit 7a12b4ac93.
After fixing that bu
I'm experimenting with using custodians to manage threads (on Racket 7.8
[cs]) and encountering behavior I don't understand.
I start a looping thread `t1` under a new custodian `c1`.
I then shutdown `c1` and expect `t1` to stop looping. If I started `t1`
with `thread` then this expectation is
At Sat, 7 Nov 2020 16:42:43 +0100, Dominik Pantůček wrote:
> My current understanding is that the best performance you get from
> unsafe operations while using safe operations as hints for the flonum
> unboxing algorithm, right?
I'm not sure I understand what you mean, but I don't think unsafe
ope
Wow, you are faster than I :)
On 07. 11. 20 15:36, Matthew Flatt wrote:
> At Fri, 6 Nov 2020 12:45:46 -0700, Matthew Flatt wrote:
>> I will investigate faster option. A primitive without conversion could
>> make the safe `flvector-set!` slightly faster, too, by avoiding a
>> redundant check.
>
>
At Fri, 6 Nov 2020 12:45:46 -0700, Matthew Flatt wrote:
> I will investigate faster option. A primitive without conversion could
> make the safe `flvector-set!` slightly faster, too, by avoiding a
> redundant check.
Long story short, I added flvectors to the Chez Scheme level as of
v7.9.0.4. With
5 matches
Mail list logo
