Nick Williams wrote:
Scott wrote:But communication with child processes will never be synchronous, you have too many steps to go through to communicate with child processes (via pipes, or other methods, nothings going to be _RIGHT_NOW_)
[...]
If you're really only storing data, you really should use an object OR package in the ways I mentioned above. Atleast, if you have any desire to maintain efficiency.
Now here I must note, that I didn't come up with the idea of removing inter-session calling all together. I found the idea on the wiki. Now I'm not gonna name names, and I'm not gonna drag others in, because I am a proponent of the idea. I think inter-session calling breaks POE Design patterns. Forcing inter-session communication to be done via post()ing helps force people using the POE Framework to let POE do its thing, and stops people from doing things like creating sessions just for the sake of creating sessions.
I also have a need for inter-session calling, so I want to add my tuppence into this :-). Hopefully, my description below isn't so abstract to be non-sensical, but will convey why I need it.
I have a fairly complex system that runs various background monitoring tasks (using Wheel::Run) and also takes in requests from the network. Each new network request gains its own session for it to process all work. This work may take some time, also creating new Wheel::Runs, etc. The effect of some of the requests needs to change the frequency of the background monitoring that's going on, or needs to change some of the 'global' data that dictates the manner in which the background processing is run. There is no synchronisation/locking of global data, so the only way to do that is to ask the session owner to make the change. When that type of event happens, we need to get a cross-session event to take place. We can't use post() all the time, because sometimes we need to ensure that the change happens before anything else in the queue is fired off, else we get out-of-order processing. It's a rare thing (only need this twice, in a codebase of ~20k lines of perl), but it does happen. I cannot see (within the constraints of our architecture) how I can achieve this without inter-session call functionality.
Nick.
I suppose the link I seem to be missing is why a subroutine call would not be satisfactory for this.
a subroutine call would be in the context of the currently active session, which is a session just there to deal with the current network request and should go away after that. Therefore I don't want to call the 'create-new-probe-which-will-fire-every-60secs' subroutine, because anything it creates would become a child of this current session and any alarms/delays it wants to set, and any events it wants to post to it's parent would go to me (this session) and not to the parent session which is looking after all background monitoring tasks.
[...]It's hard to describe the system we've built in a small email, so I'm sorry for the confusion. My point is that in the possibly bizarre architecture we've built, we have a need for cross-session calls. Potentially, I could re-architect things to avoid that, however I'm not sure how at the moment (due to lack of locking in the global data) without very severe changes. Purity of design is great, but if it means I have to spend a week re-architecting compared to the current simple architecture.... can you see where I'm coming from? Pragmatism won in our system (funny that - same reason we're using perl and POE to start with...).
but then again
I'm not even sure I really understand what you're saying.
- Scott
Nick
