Can't Perl Be Event Driven Too?

Discussion in 'Perl Misc' started by John Black, Oct 14, 2013.

  1. John Black

    John Black Guest

    I keep hearing about how Javascript / Node.js is great for web servers because its "event
    driven" and "non-blocking"... Statements like this are often made: "JavaScript happens to be
    a great fit for writing servers due to its event-driven nature."

    But how hard is it to use Perl for an event driven application like a web server. Seems to
    me you can just have a main thread processing the event requests. For each request, it
    spawns a thread to go off and do the work which reports back when done. The main event
    queueing thread is not "blocked" while the other threads are doing the work. Presto - event
    driven... What am I missing?

    John Black
    John Black, Oct 14, 2013
    #1
    1. Advertising

  2. John Black <> writes:

    > But how hard is it to use Perl for an event driven application like a
    > web server.


    Very easy.

    > Seems to
    > me you can just have a main thread processing the event requests. For each request, it
    > spawns a thread to go off and do the work which reports back when done. The main event
    > queueing thread is not "blocked" while the other threads are doing the work. Presto - event
    > driven... What am I missing?


    Event driven generally means there's only one thread doing
    everything. Threads are costly, thus your setup cannot serve many
    concurrent connections.

    However, there are POE [0] and AnyEvent [1], which are great for doing
    event-driven stuff with Perl.

    [0]: http://search.cpan.org/~rcaputo/POE-1.356/lib/POE.pm
    [1]: http://search.cpan.org/~mlehmann/AnyEvent-7.05/lib/AnyEvent.pm
    --
    Marius Gavrilescu

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.15 (GNU/Linux)

    iQIcBAEBCgAGBQJSW6V2AAoJEMoENb5ewbNi02MP/jwngoF1tWzCe5y5Rdeg8lQS
    AQL8iXIHY8niXaUsqt4yRoeYT84hHSd6c69mRnOJN8d8UezgVT2zAU2DABYp9JkH
    cBxuLhy6JQCMMFVwBn88dFq0gQ1Au4t6SL/VlL3v/1/caEkUDqkKQeVGv+hV74nm
    r2MXhAtrnz6pMA64rU5ToQ2VUJ/orOiBJPVNug7SjWcF6uuJYcSBS8PtrsoJGIJU
    DYgS2PZKF2RYu4Zi4zcXYcpaiyriDoIO+6JCErO2Yd0izKgmrsEbHjXHQAn0OIRc
    52rlEFoRMI4KNhKIm0I+5DXafQLzp+vZx/dwu2EsbbRFzfAlUQroWlAlOiCVEb91
    nmbAcyk7fE9s6JBikx4YeHlG1nkpr3xp0ippIr0iS78Z2rbDtAG4vMlAVwH81fFU
    pePWYx9Lnfj/HNRVVp+/pp5S9vRuYEVthsJhjbr3FNClzZtyBL5wdgSkkjrkdlJJ
    e9+16rWnb/Pq54FNTMLTlXo2QIbjwwocC8ttvdjEkppQR0x7SsnHn84pdDBk/DdW
    cqTPOVSiY625lKSkljtCd1rAHfkPq2upCWblZ7I76UrrjPOy1QsvPoXvw6T44B6f
    NEHpfe+RafUDZ4g3qRUvh5QcwWzpaXE+TUmABDXM5av0iA0ak9vtuDauULERpEVZ
    0fHIk+ZfmB/+lplCPiaK
    =yIOb
    -----END PGP SIGNATURE-----
    Marius Gavrilescu, Oct 14, 2013
    #2
    1. Advertising

  3. In article <-september.org>,
    John Black <> wrote:

    > I keep hearing about how Javascript / Node.js is great for web servers
    > because its "event
    > driven" and "non-blocking"... Statements like this are often made:
    > "JavaScript happens to be
    > a great fit for writing servers due to its event-driven nature."
    >
    > But how hard is it to use Perl for an event driven application like a web
    > server. Seems to
    > me you can just have a main thread processing the event requests. For each
    > request, it
    > spawns a thread to go off and do the work which reports back when done. The
    > main event
    > queueing thread is not "blocked" while the other threads are doing the work.
    > Presto - event
    > driven... What am I missing?
    >
    > John Black


    What are you trying to do? You're asking general questions with massive
    assumptions behind them. It's like asking if a bus will get you to
    Detroit when all you may really need is to get to the library down the
    road.

    And yes, perl code can be written to sit in a loop looking for events.
    It's more for procedural programming but it can also do OOP.

    --
    DeeDee, don't press that button! DeeDee! NO! Dee...
    [I filter all Goggle Groups posts, so any reply may be automatically ignored]
    Michael Vilain, Oct 14, 2013
    #3
  4. John Black <> writes:
    > I keep hearing about how Javascript / Node.js is great for web servers
    > because its "event driven" and "non-blocking"... Statements like this
    > are often made: "JavaScript happens to be a great fit for writing
    > servers due to its event-driven nature."


    This statement doesn't mean very much except that the person who made it
    is almost certainly repeating something she heard elsewhere without
    actually knowing what the terms mean.

    > But how hard is it to use Perl for an event driven application like a
    > web server. Seems to me you can just have a main thread processing
    > the event requests. For each request, it spawns a thread to go off
    > and do the work which reports back when done. The main event queueing
    > thread is not "blocked" while the other threads are doing the work.
    > Presto - event driven... What am I missing?


    NB: The text below is heavily simplified in order to explain the general
    principle.

    'Blocked' usually means 'process called into the kernel in order to
    receive input on file descriptor ... and now waits until some is
    available'. In a situation where many independent clients talk to a
    single server using individual TCP connections, eg, in a web server, the
    server obviously can't block on a single connection until input data
    becomes available and continue to deal with the connections of other
    clients at the same time. A so-called 'concurrent TCP server' is needed
    in this case. A simple way to provide that is to create a new process
    (or thread, although perl threads are not light-weight compared to perl
    processes) per client so that each process deal with exactly one TCP
    connection and is thus free to make potentially blocking I/O calls as it
    suits it. A somewhat more complicated but usually more efficient way is
    to use a so-called 'event-driven server': In this case, the process
    blocks in system call which waits for input ('events') on multiple file
    descriptors concurrently. As soon as data becomes available on any of
    them, the process returns to userspace, reads the available data and
    continues "where it left of last time" (based on somehow recorded state
    information) for this TCP connection and then the next and the next and
    so on, until all available input has been consumed. Afterwards, it goes
    to the 'wait for something to happen'.

    Unfortunately, the only thing perl supports out of the box for this is
    select (which has two meanings in Perl) which is the oldest (AFAIK,
    invented for 4.2BSD) API providing this facility and the most widely
    supported (meaning, it will work on Windows as badly as anywhere
    else). Depending on the system you are using (or 'the systems you plan
    to support') other interface with more or less useful/ sensible perl
    support may be available.

    Because 'generalized event loop' (with 'cooperative userspace threading'
    hiding ready to ambush in some dark corner nearby) is an all-time
    classic of recreational programming, you'll also find uncountable
    numbers of mutually incompatible 'generalized event loop' implementation
    on CPAN (most of them presumably abandonware).
    Rainer Weikusat, Oct 14, 2013
    #4
  5. John Black

    John Black Guest

    In article <>, says...
    >
    > In article <-september.org>,
    > John Black <> wrote:
    >
    > > I keep hearing about how Javascript / Node.js is great for web servers
    > > because its "event
    > > driven" and "non-blocking"... Statements like this are often made:
    > > "JavaScript happens to be
    > > a great fit for writing servers due to its event-driven nature."
    > >
    > > But how hard is it to use Perl for an event driven application like a web
    > > server. Seems to
    > > me you can just have a main thread processing the event requests. For each
    > > request, it
    > > spawns a thread to go off and do the work which reports back when done. The
    > > main event
    > > queueing thread is not "blocked" while the other threads are doing the work.
    > > Presto - event
    > > driven... What am I missing?
    > >
    > > John Black

    >
    > What are you trying to do? You're asking general questions with massive
    > assumptions behind them. It's like asking if a bus will get you to
    > Detroit when all you may really need is to get to the library down the
    > road.


    For education, I wanted to learn to write a web based app on a cloud type of structure like
    Heroku. I wanted to use Perl but now I notice Heroku doesn't even support it!

    "Write apps in your language ? we support Ruby, Node.js, Clojure, Java, Play, Python and
    Scala."

    Why would they support Ruby and Python but not Perl??

    John Black
    John Black, Oct 15, 2013
    #5
  6. John Black

    John Black Guest

    In article <-september.org>, says...
    >
    > I keep hearing about how Javascript / Node.js is great for web servers because its "event
    > driven" and "non-blocking"... Statements like this are often made: "JavaScript happens to be
    > a great fit for writing servers due to its event-driven nature."
    >
    > But how hard is it to use Perl for an event driven application like a web server. Seems to
    > me you can just have a main thread processing the event requests. For each request, it
    > spawns a thread to go off and do the work which reports back when done. The main event
    > queueing thread is not "blocked" while the other threads are doing the work. Presto - event
    > driven... What am I missing?


    Thanks all who replied. I now have several CPAN modules to investigate as a starting point!

    John Black
    John Black, Oct 15, 2013
    #6
  7. >>>>> "JB" == John Black <> writes:

    JB> I keep hearing about how Javascript / Node.js is great for web
    JB> servers because its "event driven" and "non-blocking"...

    The essential part of this is that it is in the nature of Node.js to be
    asynchronous and to use callbacks and deferred execution. Because of
    the emphasis on asynchrony in the entire stack, because very few calls
    actually block for any reason, it's possible to write asynchronous code
    at the highest level.

    While this is possible in Perl (and really not that difficult), the lack
    of emphasis on asynchrony and non-blocking calls in Perl overall means
    you need to take extra care to make sure that nothing blocks.


    JB> But how hard is it to use Perl for an event driven application
    JB> like a web server. Seems to me you can just have a main thread
    JB> processing the event requests. For each request, it spawns a
    JB> thread to go off and do the work which reports back when done.
    JB> The main event queueing thread is not "blocked" while the other
    JB> threads are doing the work. Presto - event driven... What am I
    JB> missing?

    This is not event-driven in the sense that node.js is event driven.

    Event-driven code generally has a single thread of execution and a task
    queue. To make your code event-driven, you would have to structure it
    as small blocks of code that respond to events, none of which contain
    any blocking code that you have to wait for.

    So your web server: it receives a request. It parses the request.
    Then it tries to open the file to serve (for simplicity, let's make this
    a stupid web server that doesn't do anything dynamic). Since this is
    likely to block, it does it asynchronously, which means that instead of
    waiting for it to return, the runtime will trigger an event when it
    occurs. So when the file-to-serve-is-opened event fires, we then read
    the first chunk of the file and pass it to our output socket. Both of
    those can block! so now we have the file-chunk-ready event and the
    output-socket-ready event. Eventually we get the file-has-ended event,
    and we close the socket.

    But the key is, single thread of execution, with a priority queue of
    events that need to be responded to; and the response to an event may
    include firing off OS calls that will result in other events being
    queued when they return.

    (Practically, writing in Node reminds me a lot of cooperative
    multitiasking: if you do it all correctly and there are no bugs, the
    fact that you have fewer safeguards means you can get screamingly fast
    performance. However, when you have a bug, it can take the entire
    server down, and not just the thread/process you're in.)

    Charlton




    --
    Charlton Wilbur
    Charlton Wilbur, Oct 21, 2013
    #7
  8. >>>>> "JB" == John Black <> writes:

    JB> For education, I wanted to learn to write a web based app on a
    JB> cloud type of structure like Heroku. I wanted to use Perl but
    JB> now I notice Heroku doesn't even support it!

    JB> "Write apps in your language ? we support Ruby, Node.js,
    JB> Clojure, Java, Play, Python and Scala."

    JB> Why would they support Ruby and Python but not Perl??

    Politics. A lot of the external factors around Perl have made it less
    popular than it by rights ought to be: in particular, the early missteps
    in Perl 6 development took away a lot of momentum; and where 10 years
    ago Perl was the obvious choice in its subfamily of languages, nowadays
    there are a dozen viable competitors.

    Charlton


    --
    Charlton Wilbur
    Charlton Wilbur, Oct 21, 2013
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Peri
    Replies:
    6
    Views:
    8,040
  2. HG
    Replies:
    0
    Views:
    354
  3. F
    Replies:
    1
    Views:
    409
  4. christopher diggins
    Replies:
    4
    Views:
    397
    christopher diggins
    Dec 21, 2004
  5. jose luis fernandez diaz

    Using signals as a event driven framework

    jose luis fernandez diaz, May 3, 2004, in forum: C Programming
    Replies:
    6
    Views:
    406
    Xenos
    May 3, 2004
Loading...

Share This Page