Is bidirectional msg/rpc supported?

[tianjianjiang]

In case I misunderstood the code and the examples, looks like it's always from parent to child processes for the time being?

Thank you!

[WyriHaximus]

The underlying messenger package theoretically supports it but it isn't fully tested and exposed in the pool. Shouldn't be to much work tbh.

What is your use case? :)

[tianjianjiang]

Hi @WyriHaximus,

Thank you for such a swift reply.

My tentative case is that child processes check whether their parent is still running or not, assuming the parent can encounter a timeout itself or properly manage aborted connection (the latter is a bit impractical though), and the parent won't be able to terminate child processes normally.

However, for orphan process handling the above isn't the only approach, so my case can be more abstract as any other bidirectional interprocess communication.

Anyway, I will try to find some free time to try to expose the messenger. :)

Thanks again.

[WyriHaximus]

The messenger package listens on unexpected STD* stream exits for the specific reason of the parent dying. So when ever the parent dies for what ever reason so do the children and they don't turn into orphan processes.

But there could/would(/should) be use cases aside from emergency handling to have bidirectional communication. The Messenger object from the messenger package is used for both the child and client process to communicate and exposes the register and call methods for RPC's on both sides. It how ever isn't tested and the register method isn't exposed on pools.

A first step would be adding bidirectional example to the messenger, making sure it works, and then tag any improvements if necessary. When the messenger is up for the task adding it to the pool would be the next step.

[tianjianjiang]

I had a glimpse of the STD* event handler and thanks for the clarification.

What I've encountered is somewhat obscure because of lacking information. A parent dispatches hundreds queries to child processes of artisan console command of elasticsearch. There were several occasions that some child processes stayed up for hours consuming 100% CPU time.

So I'm trying to gather more traces and also enhance the communication ability of the pool if at all possible.

Thanks for the advice.

[WyriHaximus]

For that STD* fix make sure you run 2.7.1 of the messenger.

Interesting, I've tested the pool up to 500+ simultaneous child processes without issues. However those where clean purpose build processes with no framework or other packages overhead. It could be that somewhere along the way an error occurs and that it is causing issues for the communication.

I gladly help out, and bidirectional communication would be something I'de love to have in this project.