Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re: Doing an Input->process->Output cycle with AnyEvent? (was: error: "recursive blocking wait detected")

by BrowserUk (Patriarch)
on Oct 16, 2010 at 22:13 UTC ( [id://865737]=note: print w/replies, xml ) Need Help??


in reply to Doing an Input->process->Output cycle with AnyEvent? (was: error: "recursive blocking wait detected")

Sorry for this, but I'm going to ask what might be a really dumb question.

As I read your post: you can't process until you've obtained some input; and you can output until you've processed that input. Correct?

If so, that sounds like a serial process to me:

while( <> ) { ## do something to $_ print; }

So why would you use a behemoth like AnyEvent to do that?


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^2: Doing an Input->process->Output cycle with AnyEvent? (was: error: "recursive blocking wait detected")
by isync (Hermit) on Oct 16, 2010 at 23:33 UTC
    I expected this to come up. And to be honest: I am not quite sure if AnyEvent should *really* stay onboard or not...

    Well, the verbose explanation is that this input output thing here is part of a larger system, where multiple things go on simultaneously. AnyEvent's timers come in handy, I've got kind of a main-loop... stuff like that. So I thought: I think that's where others would throw an event framework into the mix. So when I needed to add this input/output interface here, a component which influences the various parts of the system, I thought it would be a consistent move to model this with AnyEvent's tools as well.
    Wrong asumption?
      So when I needed to add this input/output interface here, a component which influences the various parts of the system, I thought it would be a consistent move to model this with AnyEvent's tools as well. Wrong asumption?

      Hm. Let me be up-front and say: I don't understand why anyone would voluntarily choose to use an event-driven system on a pre-emptive, multi-tasking operating system. The phrase that comes to mind is: "Like buying a dog and barking yourself".

      It always reminds me of one of those plate-spinning acts. The guy or girl is running around splitting their time between trying to load up new plates onto poles, whilst keeping the existing ones spinning fast enough to stop them falling. Everyone gets behind them cheering them on. Unwittingly helping them out by collectively "whoooa"ing, whenever one of them starts to wobble violently. Eventually they either complete the poles available or their timeslot comes to an end and everyone applauds with admiration. But in the end, we all know they're all going to come crashing down.

      In the past, I've had to program such systems, because there was no other option available. They can be made to work well, and can be very efficient. But at what expense? They are so complicated and fragile. Difficult to program; a nightmare to debug; and horrendously expensive to maintain. One change to the specification; or the need to move to different hardware; and you're into a game of having to re-tune every part of the system.

      And once you're locked into a given framework, nearly everything you want to do requires a "special version" of everyday modules. Just witness the hundreds of modules that turn up when you search for AnyEvent::* or POE::*. And see how many of them are specially adapted versions of common, well used modules like ...::LWP::* and ...::NET::* and ...::IO::*. And then there are the dependency chains. A bug arises and a fix is a applied to one of those core modules, but then you have to wait for that fix to make it's way through the chain into the specialist version you're using.

      Their proponents will tell you horror stories of deadlocks and inversion chains, and all sorts of other nasties, if you bring up threads; but as you've discovered, you don't avoid synchronisation issues with an event-based system. Indeed, you have to use it to try re-create a simple serial sequence of DoA() then DoB() then DoC().

      You want to read-process-write, see the loop above. You need to do other things while that goes on:

      async{ while( <> ) { ## process $_ print; } };

      Now you can!

      Let that well-tested, highly tuned, pre-emptive multi-tasking scheduler take care of making sure that when things need doing, they get done. None of this interrupting everything you're doing, every 1/10th of a second, to run around everywhere else asking (polling): Does anything need doing? Does anything need doing?

      Don't feel the need to counter this--it's just my view on things--but I've yet to see an event-driven application that wasn't simpler written and maintained using threading. That's actually a challenge that I'd love to see someone take up. But I doubt they will. I'll let you decide the reason why not :)


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
        Thanks for your opinionated post! So far, I've only taken a few steps into the event-framework-world. After reading a bit of POE docs I soon tripped about more and more comments which said "avoid POE". AE promised to master them all. And when I started to dive into AE, exactly what you've described began to happen: I found myself writing a while loop again AND event triggers and listeners etc.

        An old-fashioned serial loop structure plus some threading might not have the bells and whistles of events, but your post convinced me to try the "pragmatic path" first. Keep it simple stupid, once again. I think I need to re-think my design...
        Hm. Let me be up-front and say: I don't understand why anyone would voluntarily choose to use an event-driven system on a pre-emptive, multi-tasking operating system. The phrase that comes to mind is: "Like buying a dog and barking yourself".

        Really. I don't understand, why anyone would voluntarily choose to use multi-threading in situations when there are lots of interactions between threads. The mess of mutexes and semaphores with really high chance of dead-locking - that's what such application looks like.

        The rule is simple. Use tools that are appropriate for the work. If the actions are short and interaction is high, then event-driven system is the best. If the actions take longer time and don't interact much, then multi-threading is your choice. And of course, don't bother with all of this if your application is very simple. This approach will speed up the execution and simplify the development. All you need is good understanding of the event-driven approach.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://865737]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others surveying the Monastery: (8)
As of 2024-03-28 09:13 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found