Re: LWP::UserAgent non-blocking calls

Sometimes breaking a big program into smaller programs focused into doing one thing, can work nicely and be able to deal better with future long-calls. E.g. separate this call into a new script which does exactly that and when is done, saves the results in a redis db whose checking takes millis. Or use some kind of "bus" to connect them all. D-BUS for example.

Edit: additionally what LWP gets back is not a perl data structure or object, so you will not need to de/serialiase when passing that data around.

Comment on Re: LWP::UserAgent non-blocking calls

Replies are listed 'Best First'.
Re^2: LWP::UserAgent non-blocking calls by cavac (Prior) on Oct 22, 2024 at 08:11 UTC
This is for a modular framework with a webserver and configurable workers. The workers automatically have database connections and Net::Clacks access. The workers and non-forking, single threaded. And i prefer to keep it that way to simplify development and debugging. And no, using something like redis is definitely not an option, a lot of my stuff runs on embedded cash registers that only sport 4-8 gigs of RAM... PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP Also check out my sisters artwork and my weekly webcomics	[reply]
Re^3: LWP::UserAgent non-blocking calls by bliako (Abbot) on Oct 22, 2024 at 09:42 UTC
`This is for a modular framework with a webserver and configurable workers.The workers automatically have database connections and Net::Clacks access.` That's great. You already have a database and a communication bus, exactly what functionality redis/D-Bus, in my suggestion, would have provided. The crucial question is why, if and when the workers block (as workers do regularly block), the whole system blocks? I would decouple the workers from the "system", whatever that is, even more. Use the bus to send requests to the LWP worker (edit: LWP worker script) which posts its response, when it comes, to the bus+db and poll the bus (non-blocking) at the supervisor. I guess it is simpler for me to say these than to implement or adjust an already implemented system.	[reply] [d/l]