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 always be able to share data between these os threads as long as I just use standard synchronization techniques? Is the question of sharing data among manual activated os threads less complicated than places? Is a new manual thread a new racket place or is it not a place at all?
Thanks! > On Oct 1, 2020, at 8:21 AM, Matthew Flatt <[email protected]> wrote: > > 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 data among places is complicated. For > BC, different places use different allocators, so it basically doesn't > work (although it's possible to use no-moving objects that are GC > managed but still retained in the original place as long as they're > accessed anywhere else). For CS, there's currently only one allocator > for all places. That probably won't change, but it seems likely that CS > places will become more distinct in some way in a future > implementation, such as having different symbol tables while still > having the same allocator. > > You can share memory allocated in 'raw mode among places in both BC and > CS, since that amounts to calling the C library's `malloc`. Going that > direction may end up similar to using something like zeromq, though. > > You're right that there's not currently a way exposed to get the > identity of the current place or to check for being in the original > place. > > Matthew > > At Thu, 1 Oct 2020 07:38:09 -0500, Nate Griswold wrote: >> 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 <[email protected]> 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 >>> something like zeromq or file descriptors). I wanted to allow garbage >>> collection and `#:in-original-place?` dependent ffi libs to work correctly. >>> Then i guess I need to keep my original place in scheme code and *not* >>> `Sdeactivate_thread`ed most of the time to make this work. I had the idea >>> from what you said that i might Sactivate_thread a completely different >>> os-level thread in order to call into scheme using say racket_apply on >>> `place-channel-put`. Can i do this or no? I was thinking no because... >>> >>> From the docs for `#:in-original-place?`: >>> >>> """ >>> If in-original-place? is true, then when a foreign callout >>> >> <https://docs.racket-lang.org/foreign/foreign_procedures.html#%28tech._callout% >> 29> >>> procedure with the generated type is called in any Racket place >>> <https://docs.racket-lang.org/reference/places.html#%28tech._place%29>, >>> the procedure is called from the original Racket place. Use this mode for a >>> foreign function that is not thread-safe at the C level, which means that >>> it is not place-safe at the Racket level. Callbacks >>> >> <https://docs.racket-lang.org/foreign/foreign_procedures.html#%28tech._callback >> %29> >>> from place-unsafe code back into Racket at a non-original place typically >>> will not work, since the place of the Racket code may have a different >>> allocator than the original place. >>> """ >>> >>> I guess this means os threads use completely different allocators and >>> sharing data among different `Sactivate_thread`ed threads doesn't make any >>> sense at all. Is there any way to do this (command my places using the >>> basic chez and racket funcs like racket_eval and Scons and racket_apply) or >>> should i just use messaging over zeromq or an fd to my main thread? Maybe >>> if place descriptors are guaranteed shared among all os-level threads then >>> i can do it. I guess if `#:in-original-place?` exists there must be some >>> way to do it, but maybe it's not exposed to the user. Also, is there any >>> way to get the place descriptor for the current place or the main place? I >>> didn't see any in the docs. I guess i should just start reading the racket >>> source at this point. >>> >>> Also maybe i'm missing a simpler solution. Any help would be appreciated. >>> Thanks. >>> >>> Nate >>> >>> >>>> On Mon, Sep 14, 2020 at 6:47 AM Matthew Flatt <[email protected]> wrote: >>> >>>> 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 shut down, and by using racket_apply or some such) then gc >>>> can >>>>> happen. But i do not know about the other threads that racket has >>>> spawned. >>>> >>>> In Racket CS, you can enable GC without the main thread by deactivating >>>> the thread. At the Racket level, use `#blocking? #t` for a foreign >>>> function to deactivate the current thread while calling the function. >>>> At the C level, you can use `Sdeactivate_thread` and >>>> `Sactivate_therad` from Chez Scheme's API. >>>> >>>> Racket BC doesn't have a notation of deactivating a thread. Most GCs >>>> with BC can run in separate places even without the main thread active, >>>> but the main thread is needed when there has been enough shared-space >>>> allocation that all threads must be involved. >>>> >>>> One caution for both CS and BC, though: Some foreign-library bindings >>>> use `#:in-original-place?` to make use of the foreign library >>>> single-threaded by routing all calls through the main place. That >>>> requires the main thread to be active. >>>> >>>> >>>> Matthew >>>> >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Racket Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/racket-users/CAM-xLPp_vT-DadahcHh57d9EB5nw8mH >> NeVzK1Pp42GVLCzbySA%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/3F9C6893-BFF1-4C0B-8382-256B0B062542%40gmail.com.
