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 <mfl...@cs.utah.edu> 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 <nategrisw...@gmail.com> 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 <mfl...@cs.utah.edu> 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 racket-users+unsubscr...@googlegroups.com. >> 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 racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/3F9C6893-BFF1-4C0B-8382-256B0B062542%40gmail.com.
