[Chapel-developers] [GSOC2016]Interested in web-server task

[赵亮 <you...@gm...>]

Hi, everyone.

  I'm a postgraduate student in Xidian University, Xi'an, China. I would
like to propose the web-server task for Google Summer of Code. I'll share
some basic ideas about the task-aware socket/net library. Need your
feedbacks.
  I used to program a lot in C/C++.  I would like to program in C/C++,
especially when it comes to performance issues. I had an internship as
backend developer at Alibaba Group, working on our distributed file system.
We have a huge amount of data. C/C++ are good at this, high performance. I
learned a lot though the way. But the traditional network programming model
is not quite human-oriented. It's full of callbacks, and would be a hell if
you try to do some debugging. I'll definitely not vote for exposing the raw
select/poll-like API to our end users as chapel's net library.
  "We deserve something better". Chapel is a productive programming
language. I don't think I would call it productive if I still have to deal
with all these kind of callbacks. I'm thinking we should provide something
like this as a modern programming language:

> ln = net.Listern("tcp", ":80")
> for conn in ln.Accept() do
>       begin handleConnectin(conn)

We only expose blocking API to chapel user while handling non-blocking
async networking underneath(in the task layer). This's a much  more
productive approach. The coroutine way is basically something modern
language like go-lang provided. I have checked out the implementation
in golang, gevent, tornado during the past days. They basically did  the
something: task-switching when the blocking API get called, using the
select/poll API on a separate task/thread to notify the upcoming IO event,
though they differ from different schedule strategies.
  Chapel has several task implementation
<http://chapel.cray.com/docs/latest/usingchapel/tasks.html>s(light-weight
qthreads, fifo pthread, massivethreads). I have glam through the qthreads
source code. It has built-in async system call scheduling support. But
currently, chapel's qthreads task bindings and the standard library hasn't
leveraged qthreads' built-in async system call feature. There would be a
lot of decision-making, API design, and coding if I try to d o the
implementation. But also, the outcome will be remarkable. The network
programming in chapel will be a pleasure with a huge performance
improvement. And writing a web server would be quite easy. The fifo/pthread
implementation could just use the blocking system call. Leave the schedule
job to the OS. Haven't do much investigation with the massivethreads
library yet.

Would you take this as a possible approach? Am I proposing something too
big for a three-month  job? What would you say? Any suggestions?

 The mailing list archive has some related discussion. [tasking layer and
asynchronous gets
<https://sourceforge.net/p/chapel/mailman/message/27398790/>] [request for
review: net moudule
<https://sourceforge.net/p/chapel/mailman/message/31744487/>].

--zhao