When using custodian-limit-memory, is there a way to know when a custodian has been shut down due to reaching the memory limit?

Is it possible for a dynamic-place to inherit the state of its parent place? I’m thinking of fork-like semantics. I assume not, but just wanted to double check in case I missed something. My specific use case is I have a central process that dispatches jobs to a pool of worker places and when those places boot up I need them to load the module that runs that central process. The way I have it set up right now, the central process sends each new place a module path and then each place dynamic-requires that module, but that can be pretty slow.

@popa.bogdanp No, it isn’t possible. Though to be clear, the overhead should only happen on startup, right? Since you’re pooling the worker places (which is usually the right approach).

That’s right, the overhead is only at boot time so it’s not a huge deal. The reason I’d like it to be a bit faster is because the process will often be reloaded during development and waiting for the workers to boot up in those cases can be a bit annoying. I think what I’m going to do is defer some of that work by making the worker places require the module after they receive the first job rather than immediately when they start up.

Also, this1 feels a little bit icky/like it could come back to bite me later.

Got it, that makes sense. You could possibly try to do some kind of live reloading in the individual places to avoid having to respawn them every time, via dynamic-rerequire, but that would certainly be more involved.

hello is exists tutoral with CI/CD on gitlab with drraket project?

@wwall not for gitlab, but for github & travis there’s https://github.com/greghendershott/travis-racket and for github actions you can look at https://github.com/Bogdanp/setup-racket

thanks

I’m translating some Java code to Racket. For heavily overloaded methods, is it best to have a prefix name and then just number them (e.g. name–1, name–2, etc), essentially “de-overloading” the calls at the calling level?

No, that’s not reported/recorded anywhere. I think once created a nested custodian with a memory limit on the parent and only the child exposed, so that if the parent is shut down, it could only be due to the memory limit.

@steveh2009 Can you use optional arguments to reduce the number of overloads needed?

Ok thank you. It may be a good idea to document this and maybe to guarantee this somehow in the future, as currently it’s a little hard to assess how much I can rely on this.

The use case is a search algorithm that i need to kill on time-out or on out-of-memory.

can somebody show example for struct-doc?

Racket has a discord server! https://discord.gg/6Zq8sH5

the reason for this is not discord features - it is that discord is popular and familiar for many who don’t use email, slack, google groups or reddit.

What’s the relationship between thread and place? I was tipped off to place/context for simplifying my code, but my current code uses thread.

Most programs use threads, which provides concurrency (the illusion of parallelism). If you need real parallelism (i.e. need more than one cpu), you can use places. Threads are the easiest to work with.

@pavpanchekha Use thread to manage concurrent communication tasks (IO). Use places to manage parallel computation, i.e. CPU-bound work. Places are unlikely to help you much with IO-bound tasks like reading and writing files (or at least, they’re unlikely to do as well as threads and will be much harder to use.)

Hmm, so I would convert to places, then? Herbie is very CPU bound.

If you have tasks of the form “take smallish in-memory input messages, do lots of CPU work, produce smallish in-memory output messages”, then I think you will get a lot of benefit out of using places. I suspect a lot of Herbie falls into that bucket.

It’s reasonable to use both threads and places in a large program. You take the CPU-intensive tasks and ship them off to worker places or place pools. Then the main place uses threads to manage IO and sending/receiving messages to worker places.