Thanks!!
> On Oct 1, 2020, at 9:37 AM, Matthew Flatt wrote:
>
> A new manual thread is not a new place. If places in CS change to have
> distinct allocators (unlikely) or symbol tables (likely), then I expect
> that activation would change to support specifying the place and use
> the original
A new manual thread is not a new place. If places in CS change to have
distinct allocators (unlikely) or symbol tables (likely), then I expect
that activation would change to support specifying the place and use
the original place by default. Individual activated threads certainly
would not have se
Cool. Thanks. I can play around with an activated thread to try and make the
calls I want. I guess i wasn’t clear on the difference between an activated
manually made thread and a place. Will manually made activated threads always
share the same allocator in new versions of racket cs? Will I alw
You're right that the main place is tied to the OS thread that is used
to start Racket, so you can't move the place over by activating a
different thread for the same place later. You can start Racket on an
OS thread other than the process's main thread, though.
The question of sharing allocated d
I looked into it, it seems to be implemented in `src/cs/rumble/foreign.ss`
using chez get-thread-id, comparing it to 0 and using a stored ref to the
original async callback queue, so looks like this is not exposed to the
user. Hm.
Nate
On Thu, Oct 1, 2020 at 6:58 AM Nate Griswold wrote:
> Than
Thanks, Matthew. That helps. I was working on my project again and this
came up again, but I still don't quite have my use-case figured out. I have
two additional (in addition to main thread place) places that i wanted to
send messages to using standard chez and racket c calls (and not relying on
s
6 matches
Mail list logo
