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
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
