What wrong solution do you think I am reaching?
Vis: I search for an async IPC module ...
For practical (rather than philosophical) reasons, I believe that looking for an async/event-driven IO module -- which by its very nature means a complete dynasty of framework-type modules -- is the wrong approach to solving the problem you describe.
Frameworks -- modules which call you back when they decide you should do something; as opposed to libraries which you call when you want something done -- are inevitably heavyweight families of modules requiring an(other) framework-author-integrated module for every new type of event or IO (eg. POE::* and Event::*). And even then, you have to be very careful to tune your callbacks so that they don't run for too long, otherwise the event processing becomes unresponsive.
The problems arise when your data processing of a single unit of data requires more time than is compatible with the response-time requirements of the IO code. You are then forced to try and break up that single unit of code into subunits handled by separate (artificial) events & callbacks; and that forces the saving and storing of intermediates states of the data between those callbacks. It all just gets complicated, messy and fragile.
If multi-core optimization is required, I can push event processing to pool of threads using Thread::Queue, right?
Arranging for multiple threads to have access to all the (internal) state used by such async-IO frameworks so that any of the event threads can respond to any of the events is nigh impossible.
Equally, segregating your possible events into two (or more) subsets so that two or more event loop threads can process them independently is also a loosing game. The problem here is balancing those subsets so that no one set becomes the bottleneck to your processing.
Though, your post didn't answer my original question.
It would be hard to answer with "look at such-and-such asyncIO module"; when the premise of my post is that you should not be considering such a module for your application.
But there is nothing to argue about here. It is just my opinion and if that doesn't fit with your philosophy, you are of course completely free to simply ignore it.
In reply to Re^3: I search for an async IPC module (...)
by BrowserUk
in thread I search for an async IPC module that transfers arbitrary-length strings (preferably binary, but ASCII is fine too) via full-duplex, keep-alive TCP connection
by anykeyman
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |