

Playframework: Async, Reactive, Threads, Futures, ExecutionContexts - sadache
http://sadache.tumblr.com/post/42351000773/async-reactive-nonblocking-threads-futures-executioncont

======
Irishsteve
The more and more issues highlighted with the playframework the better. I find
it a great piece of kit to play around with.

I've not come across much commentary with regards to 'bad' ideas inside the
framework which I should consider when using it.

------
TOGoS
So what am I paying for? I wasn't born yesterday; I know what the terms mean.
Get to the point because I don't have all day to look at some guy holding his
hat on.

~~~
sharms
My understanding was that pages which are inherently non blocking could be
blocked due to the use of shared threadpools and by default leveraging the
same execution contexts.

I would love to understand if this is a problem in practice, or if there are
other practical implications.

~~~
anorwell
It's definitely a real, common problem, but I think the article obscures it a
bit. Blocking I/O operations using the Akka dispatcher will block that thread
while the command executes. Doing this too often will cause all the akka
threads to be blocked, stopping the dispatcher from processing more events.
Therefore, one should avoid performing blocking operations on akka threads.

In my experience, one of two things will happen in practice:

1) You use an asynchronous library for I/O calls, which will maintain its own
threadpool. This is no problem, because the I/O threadpool is independent from
the akka theadpool.

2) You want to use a synchronous library that performs I/O operations using
the caller's thread. If you must do this, you should use a separate threadpool
(ExecutionContext).

------
papsosouid
Why do people still continue to push the myth that using event driven style
with callbacks and a huge unmaintainable mess is the only alternative to
native threads? Userland threading has been around for a very long time. The
only difference between using an event driven style and using a userland
thread lib is that with userland threading the complexity of managing the
state of the various computations is done by the thread lib instead of by you.

The sooner people stop promoting the false dichotomy, the sooner people will
realize every language should do concurrency as well as haskell, and the
sooner that will actually happen.

~~~
xyzzy123
In practical terms what happens is that your clients need to have a real good
mental model of what will block and what won't.

Also it turns out event driven programming is fine when you do it, but wait
'till you have curl handles and say mysql handles and blah 'andles and foo
andles. Fork andles!

Threading sucks. Mixing event loops also really sucks.

The developer centric way of doing it (e.g. screw performance I just want it
to be correct and look nice) is really to flip to message passing and separate
"logical processes". That's our unfortunate state of the art.

EDIT: I didn't mention that I think all the userland threading libs I know of
are crap. Which ones do you think are good? P.S I'm not going to be sarcastic
or critical about it, I would really like to have portable, usable LWP in C or
C++.

~~~
rdtsc
Both suck, but I'll take threading (acutally I'll take Erlang's processes the
most) but if I had to choose between the two, I'll take threads.

> but wait 'till you have curl handles and say mysql handles and blah 'andles
> and foo andles. Fork andles!

Yup. If I have an event driven program can I use another library that is not
built on the same event driven framework?

The answer is usually no. Even if it has the nice internally composible
"futures/deferreds" feature.

An operation that is non-blocking will return some kind of a
future/promise/deferred thingy. Those bubble all the way to the top through
the API. It means you need to have 3rd party libraries and support code that
knows about them.

This is the case with Twisted (which is a nice framework) but it means having
to have a parallel universe of libraries for everything (because they have to
return deferreds or being able to be passed in deferreds).

~~~
xyzzy123
Thanks. I vigorously agree with you. I really wish I had a better way to
explain it to people who haven't been screwed by it yet.

