The mess of mutexes and semaphores with really high chance of dead-locking - that's what such application looks like.

Really? Show me. Or better yet. Show me, (real working code I can download), that does something (other than GUI or webserver), for which you believe that an event-driven architecture is the right tool for the job.

In return, I'll try to reproduce that using threads, without the need for a "mess of mutexes and semaphores".

All you need is good understanding of the event-driven approach.

Please believe me when I tell you that I do understand event-driven architectures.

It is exactly because I've done it, and then had to go through the pain of re-tuning it (the last project above), to run on faster hardware. And then add more ports and re-tune again. And then add a remote monitoring and control channel via modem, and the re-tune the whole, internecine monster all over again.

It is exactly because of that, that I don't understand why any one would choose the architecture if they had a choice.

It worked, and worked well (most of the time). But sheesh! Was it ever a bitch to maintain, upgrade and debug.

Latterly on the above project I ported it to OS/2 and used threading. What a joy. Simple, linear flows: read-ack-read-ack-read-nak-write ack. Add more ports, start more threads. Waiting for IO, just block. Need an accurate time window, raise your priority and sleep for the required number of milliseconds. Someone dials in, start a thread to talk to them. Each thread has it's own context and its own stack. No constantly shuffling data in and out of global stores each time you have to deal with something else.

Really, I've done it both ways, and I know which is easier to write, maintain and debug. Or at least, I believe I do. So prove me wrong?

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.
RIP an inspiration; A true Folk's Guy

In reply to Re^5: Doing an Input->process->Output cycle with AnyEvent? (was: error: "recursive blocking wait detected") by BrowserUk
in thread Doing an Input->process->Output cycle with AnyEvent? (was: error: "recursive blocking wait detected") by isync

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.