Can't Perl Be Event Driven Too?

J

John Black

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
 
M

Marius Gavrilescu

John Black said:
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-----
 
M

Michael Vilain

John Black said:
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.
 
R

Rainer Weikusat

John Black said:
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).
 
J

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
 
J

John Black

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
 
C

Charlton Wilbur

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
 
C

Charlton Wilbur

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
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top