Open Grinnz opened 5 years ago
Should this also consider things like IPC::Shm and others that can be used to setup a channel between two processes that were initially unrelated?
IPC::Run3 is my go to module when I need something more complex than just calling system
or exec
.
I'd also add Parallel::ForkManager
which is a really quick, easy way to speed up many programs.
I think that Parallel::ForkManager, similarly to MCE from #10 would fit better in the Async category.
For IPC::Shm, I think it would be appropriate, I am just not sure about recommending it.
These modules sound like they are more about managing processes than facilitating interprocess communication. The pipes used to shuffle data to/from those processes are of course IPC, but they seem like their secondary focus.
Maybe put these modules into a "Multiprocessing" category and fill the "IPC" category with modules which facilitate signals, shared memory, message-passing, etc?
I agree the IPC name isn't ideal. It just happens to be the namespace used for that on CPAN. Maybe something along the lines of "Running Commands", that's not great but can't think of anything better. I think it should be distinct from process management which is more like what Parallel::ForkManager and such do.
You're totally right that CPAN (mis)uses the IPC:: namespace for process-wrangling. It's probably worth continuing in the same vein to remain consistent.
System::Command and Proc::Background provide very convenient and friendly object wrappers to system commands that probably cover 90% of use cases.
An IPC category would be useful for recommendations on modules to handle running and managing processes. IPC::Run, IPC::Run3, IPC::System::Simple, and maybe even IO::Async::Process or POE::Wheel::Run.