On Mon, 8 Oct 2018 15:39:11 -0400, James Platt
wrote:
>I wonder if this has anything to do with mitigation for Spectre,
>Meltdown or the other speculative execution vulnerabilities that have
>been identified recently. I understand that some or all of the
>patches affect the performance of
On 08/10/2018 22:12, Philip McGrath wrote:
> This is much closer to the metal than where I usually spend my time,
> but, if it terns out that multiple OS processes is better than OS
> threads in this case, Distributed Places might provide an easier path to
> move to multiple processes than
On 05/10/2018 19:23, Matthew Flatt wrote:
>
> We should certainly update the documentation with information about the
> limits of parallelism via places.
>
Added PR:
https://github.com/racket/racket/pull/2304
--
Paulo Matos
--
You received this message because you are subscribed to the
Hi all,
Apologies for the delay in sending this email but I have been trying to
implement and test an alternative and wanted to be sure it works before
sending this off.
So, as Matthew suggested this problem has to do with memory allocation.
The --no-alloc option in Matthew's suggested snippet
I just confirmed that this is due to memory allocation locking in the
kernel. If your places do no allocation then all is fine.
Paulo Matos
On 08/10/2018 21:39, James Platt wrote:
> I wonder if this has anything to do with mitigation for Spectre, Meltdown or
> the other speculative execution
I have these two files:
my-test.rkt:
> #lang racket
>
> (require racket/place/distributed
> racket/runtime-path
> "my-worker.rkt")
>
> (define-runtime-path worker-path "my-worker.rkt")
>
> (define remote-node (spawn-remote-racket-node
> "localhost"
>
Just for the record, the bug seems to be known to someone :)
https://github.com/racket/gui/blob/master/gui-lib/framework/private/color.rkt#L989
On Mon, Oct 8, 2018 at 8:15 PM Robby Findler
wrote:
> I like the idea that you suggested where the parens keep their paren
> color but the rest of
7 matches
Mail list logo
