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
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
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
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:
>
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
At Mon, 14 Sep 2020 00:34:08 -0500, Nate Griswold wrote:
> If i understand correctly, in racket cs embedded if i am not currently
> running anything in the main racket thread then gc cannot happen. But the
> next time i make a call into racket on that reserved racket thread (which
> has not been
Sorry, it's all a bit simpler than i'm making it out to be.
Basically, i want to run racket from c code (embedded i guess, but i'm not
compiling any embedded c files). This is because i want to run everything
in one process. I want to have actual parallelism so that is why i'm using
places. I
On 9/13/2020 4:12 PM, Nate Griswold wrote:
Sorry, i forgot to mention this would be interfacing on the main
thread from c
does this still hold true? Like if a c call returns does it kill the
places?
Nate
I'm not really sure what you are asking: it sounds like you are wanting
to embed
The reason i'm asking is i am dedicating a thread to racket after calling
racket_boot on it.
Nate
On Sun, Sep 13, 2020 at 3:12 PM Nate Griswold
wrote:
> Sorry, i forgot to mention this would be interfacing on the main thread
> from c
>
> does this still hold true? Like if a c call returns
Sorry, i forgot to mention this would be interfacing on the main thread
from c
does this still hold true? Like if a c call returns does it kill the places?
Nate
On Sun, Sep 13, 2020 at 12:17 PM George Neuner wrote:
>
>
> On 9/13/2020 3:55 AM, Nate Griswold wrote:
>
>
> I am making an app
On 9/13/2020 3:55 AM, Nate Griswold wrote:
I am making an app that basically spawns two racket places and i want
to be able to communicate with them from c code.
Will gc happen in the two racket places if i don't keep the main
thread (the one that spawned the places) running?
Exiting
12 matches
Mail list logo
