in reply to having a container on perl VMs is good ?

G'day xiaoyafeng,

Unfortunately, this seems to fall into "XY Problem" territory: you've indicated that you think "management container" is a solution (Y); you haven't specified what problem (X) you want this to solve (except in a very general sense).

"... let perl having more power and better face on the modern multi-core environment."

That sounds like what MCE achieves. This has a lot of documentation: it's nicely laid out, and has many examples (including a specific MCE::Examples page), but will still require a fair bit of reading. A couple of suggestions that seem to fit with what you're asking: "GLOBALLY SCOPED VARIABLES AND MCE MODELS"; "MCE->gather()".

"... container on perl VMs ..." [from title]

I was unsure what you meant by this. For $work, I've set up a VM in which I run applications that use Docker images with 15 different Perl versions. Each image uses code & data specific to its own Perl version but can also access more general, shared code & data from the VM. Perhaps this is closer to what you want.

There's also "perlipc - Perl interprocess communication". That may provide some suggestions that might be of use to you.

— Ken

  • Comment on Re: having a container on perl VMs is good ?

Replies are listed 'Best First'.
Re^2: having a container on perl VMs is good ?
by cavac (Parson) on Nov 17, 2022 at 15:29 UTC

    Another option that i nearly always use* is Net::Clacks. It allows asyncronous message broadcasting between processes. It also supports storing values on the Net::Clacks Server, similar to memcached. It supports network and Unix domain sockets (for better speed).

    * I developed that thing. Yeah shameless self promotion here, sue me...

    PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP

      Yes, although it would've been a while ago now, I do remember you posting that. The Discworld: Going Postal reference was not lost on me. :-)

      — Ken